NEXTBUS - P2RSD2
Document Type: Major
Authorized by: Saiyam Jain (2022MT11962)
Publication Date: 10th April 2025
Version Number: 3.1.1
Freaky Friday
10th April, 2025 (Week 3)
Team Members
Table 1: Single Point of Contact(SPOC)
Role Name Entry no. Email Contact
no.
TC Saiyam Jain 2022MT11962 mt1221962@iitd.ac.in 7340268982
Deputy
TC
Shivaani Hari 2022MT11273 mt1221273@iitd.ac.in 9205959258
Table 2: List of Participants
S.no Role Name Entry No Email I.F
1 Tribe Coordi-
nator and Me-
chanical Design
and Ideation
Fieldwork
Saiyam
Jain
2022MT11962 mt1221962@maths.iitd.ac.in 1.0
2 Deputy Tribe
Coordinator and
Documentation
Shivaani
Hari
2022MT11273 mt1221273@maths.iitd.ac.in 1.0
3 Activity
Coordinator-
Mechanical
Design and
Ideation Field-
work
Vagesh
Mahajan
2022MT11260 mt1221260@maths.iitd.ac.in 1.0
4 Activity
Coordinator-
Software-1
Manas
Goyal
2022MT11918 mt1221918@maths.iitd.ac.in 1.0
5 Activity
Coordinator-
Software-2
Shrenik
Mohan
Sakala
2022MT11920 mt1221920@maths.iitd.ac.in 1.0
6 Activity
Coordinator-
Market Research
Rahul
Athipatla
2022MT11277 mt1221277@maths.iitd.ac.in 1.0
7 Activity
Coordinator-
Documentation
Nilay
Sharma
2022MT12007 mt1222007@maths.iitd.ac.in 1.0
Table continues on the next page
Page 1 of 119
S.no Role Name Entry No Email I.F
8 Documentation Aahna
Jain
2022MT11930 mt1221930@maths.iitd.ac.in 1.0
9 Market Research Abhishek
Kumar
Singh
2022MT11276 mt1221276@maths.iitd.ac.in 0.3
10 Mechanical
Design and
Ideation Field-
work
Abhishek
Singh
2022MT11934 mt1221934@maths.iitd.ac.in 1.0
11 Mechanical
Design and
Ideation Field-
work
Adarsh
Singh
2022MT11285 mt1221285@maths.iitd.ac.in 1.0
12 Software-2 Aditya
Goyal
2022EE31761 ee3221761@ee.iitd.ac.in 1.0
13 Market Research Aditya
Raj
2022MT61980 mt6221980@maths.iitd.ac.in 0.3
14 Software-1 Ajaypal
Kulhari
2022EE11711 ee1221711@ee.iitd.ac.in 1.0
15 Documentation Aman Di-
vya
2022MT11293 mt1221293@maths.iitd.ac.in 0.7
16 Software-1 Ambhore
Soham
Bhaskar
2022EE11713 ee1221713@ee.iitd.ac.in 0.7
17 Software-1 Arnav
Tiwari
2022MT11267 mt1221267@maths.iitd.ac.in 1.0
18 Software-1 Arpit
Mourya
2022EE11728 ee1221728@ee.iitd.ac.in 1.0
19 Market Research Ashmit
Nangia
2022EE11989 ee1221989@ee.iitd.ac.in 1.0
20 Market Research Ayush
Nayak
2022MT11958 mt1221958@maths.iitd.ac.in 0.5
21 Market Research Ayush
Raj
2022MT11944 mt1221944@maths.iitd.ac.in 0.5
22 Software-1 Chintada
Srini-
vasarao
2022MT11924 mt1221924@maths.iitd.ac.in 1.0
Table continues on the next page
Page 2 of 119
S.no Role Name Entry No Email I.F
23 Software-1 Deevyansh
Khadria
2022EE31883 ee3221883@ee.iitd.ac.in 1.0
24 Market Research Dev
Singh
2022MT11143 mt1221143@maths.iitd.ac.in 1.0
25 Software-2 Devansh
Upad-
hyay
2022MT11931 mt1221931@maths.iitd.ac.in 0.4
26 Software-2 Dhruv
Chaurasiya
2022MT11172 mt1221172@maths.iitd.ac.in 0.7
27 Software-2 Galla
Yaswant
Venkata
Ramana
2022EE11687 ee1221687@ee.iitd.ac.in 0.8
28 Market Research Gauri
Agarwal
2021EE10715 ee12110715@ee.iitd.ac.in 0.8
29 Market Research Ishan
Bankal
2022EE31779 ee3221779@ee.iitd.ac.in 0.1
30 Documentation Ishant
Yadav
2022MT11397 mt1221397@maths.iitd.ac.in 0.5
31 Software-1 Jenit
Jain
2022EE11690 ee1221690@ee.iitd.ac.in 1.0
32 Documentation Kabir
Uberoi
2022MT61202 mt6221202@maths.iitd.ac.in 1.0
33 Documentation Kaneesha
Jain
2022MT11929 mt1221929@maths.iitd.ac.in 1.0
34 Documentation Keshav
Rai
2022MT61968 mt6221968@maths.iitd.ac.in 1.0
35 Mechanical
Design and
Ideation Field-
work
Khushi
Gupta
2022MT61973 mt6221973@maths.iitd.ac.in 1.0
36 Market Research Krish
Singh
2022MT61303 mt6221303@maths.iitd.ac.in 1.0
37 Software-2 Lakshaya
Jain
2022MT11933 mt1221933@maths.iitd.ac.in 1.0
38 Documentation Madhav
Biyani
2022EE11321 ee1221321@ee.iitd.ac.in 1.0
Table continues on the next page
Page 3 of 119
S.no Role Name Entry No Email I.F
39 Mechanical
Design and
Ideation Field-
work
Madhav
Mahesh-
wari
2022MT61975 mt6221975@maths.iitd.ac.in 1.0
40 Software-1 Mukul
Sahu
2022MT11939 mt1221939@maths.iitd.ac.in 1.0
41 Mechanical
Design and
Ideation Field-
work
Nagure
Kalyani
Para-
manand
2022MT61983 mt6221983@maths.iitd.ac.in 1.0
42 Mechanical
Design and
Ideation Field-
work
Naman
Kale
2022MT11960 mt1221960@maths.iitd.ac.in 1.0
43 Software-1 Nimkar
Abhinav
Yashwant
2022MT11943 mt1221943@maths.iitd.ac.in 1.0
44 Software-2 Niraj
Agarwal
2022MT11921 mt1221921@maths.iitd.ac.in 0.4
45 Software-1 Niranjan
Rajeev
2022EE11766 ee1221766@ee.iitd.ac.in 1.0
46 Software-2 Nobin
Kidangan
Benny
2022EE11154 ee1221154@ee.iitd.ac.in 1.0
47 Documentation Ojas
Sharma
2022EE31746 ee3221746@ee.iitd.ac.in 0.4
48 Documentation Om Goel 2022MT12071 mt1222071@maths.iitd.ac.in 1.0
49 Documentation Parth
Bhardwaj
2022MT11257 mt1221257@maths.iitd.ac.in 1.0
50 Documentation Pratyush
Sharma
2022MT61970 mt6221970@maths.iitd.ac.in 1.0
51 Market Research Pratyush
Shrivas-
tava
2022EE11660 ee1221660@ee.iitd.ac.in 0.8
52 Software-2 Praveen
Lakhara
2022MT11280 mt1221280@maths.iitd.ac.in 0.4
Table continues on the next page
Page 4 of 119
S.no Role Name Entry No Email I.F
53 Software-1 Priyansh
Prakash
Mayank
2022MT11954 mt1221954@maths.iitd.ac.in 1.0
54 Mechanical
Design and
Ideation Field-
work
Priyanshu
Jindal
2022EE11668 ee1221668@ee.iitd.ac.in 1.0
55 Software-2 Punit
Meena
2022EE11184 ee1221184@ee.iitd.ac.in 1.0
56 Market Research Rahul
Rajoria
2022MT11947 mt1221947@maths.iitd.ac.in 1.0
57 Software-2 Raman
Jakhar
2022MT11941 mt1221941@maths.iitd.ac.in 1.0
58 Market Research Ranjan
Kumar
Singh
2022MT61304 mt6221304@maths.iitd.ac.in 1.0
59 Software-1 Rijul
Rudrax
Barot
2022EE11664 ee1221664@ee.iitd.ac.in 1.0
60 Software-2 Rudranil
Naskar
2022MT11287 mt1221287@maths.iitd.ac.in 1.0
61 Documentation Sachin
Hiren
Trivedi
2022EE11190 ee1221190@ee.iitd.ac.in 0.4
62 Mechanical
Design and
Ideation Field-
work
Saksham
Kumar
Rohilla
2022EE11709 ee1221709@ee.iitd.ac.in 1.0
63 Documentation Sanya
Sachan
2022MT11286 mt1221286@maths.iitd.ac.in 1.0
64 Software-1 Sarthak
Gangwal
2022MT11275 mt1221275@maths.iitd.ac.in 1.0
65 Documentation Satvik
Prasad S
2022MT11279 mt1221279@maths.iitd.ac.in 1.0
66 Documentation Shashwat
Kasliwal
2022MT11915 mt1221915@maths.iitd.ac.in 1.0
67 Market Research Shivang
Goyal
2022MT11269 mt1221269@maths.iitd.ac.in 0.5
Table continues on the next page
Page 5 of 119
S.no Role Name Entry No Email I.F
68 Software-2 Siddharth
Saini
2022MT11283 mt1221283@maths.iitd.ac.in 0.8
69 Documentation Siya
Gupta
2022MT11274 mt1221274@maths.iitd.ac.in 1.0
70 Market Research Sparsh
Jain
2022MT11917 mt1221917@maths.iitd.ac.in 0.9
71 Mechanical
Design and
Ideation Field-
work
Suhani
Soni
2022MT61981 mt6221981@maths.iitd.ac.in 1.0
72 Software-2 Sumit
Sonowal
2022MT11296 mt1221296@maths.iitd.ac.in 0.4
73 Software-2 Suneel
Masarapu
2022MT11942 mt1221942@maths.iitd.ac.in 0.7
74 Mechanical
Design and
Ideation Field-
work
Sushil
Kumar
2022EE31765 ee3221765@ee.iitd.ac.in 1.0
75 Mechanical
Design and
Ideation Field-
work
Syna Raj-
vanshi
2022MT61974 mt6221974@maths.iitd.ac.in 1.0
76 Documentation Tanya
Jain
2022MT11935 mt1221935@maths.iitd.ac.in 1.0
77 Market Research Taru
Singhal
2022MT11922 mt1221922@maths.iitd.ac.in 0.5
78 Documentation Tatsam
Ranjan
Sharma
2022MT61969 mt6221969@maths.iitd.ac.in 0.4
79 Mechanical
Design and
Ideation Field-
work
Tirth
Punit
Golwala
2022MT11967 mt1221967@maths.iitd.ac.in 1.0
80 Software-2 Tushar
Goyal
2022MT11266 mt1221266@maths.iitd.ac.in 1.0
81 Software-1 Umang
Agarwal
2022EE11692 ee1221692@ee.iitd.ac.in 1.0
Table continues on the next page
Page 6 of 119
S.no Role Name Entry No Email I.F
82 Documentation Utkarsh
Dubey
2022MT61045 mt6221045@maths.iitd.ac.in 1.0
83 Software-2 Vatsal
Manish
Sejpal
2022MT11926 mt1221926@maths.iitd.ac.in 1.0
84 Mechanical
Design and
Ideation Field-
work
Viha
Singla
2022MT61972 mt6221972@maths.iitd.ac.in 1.0
85 Documentation Yuvraj
Singh
2022EE11715 ee1221715@ee.iitd.ac.in 1.0
Table 3: List of Participants with IF <1
S.no Role Name Entry No Email I.F
1 Market Research Abhishek
Kumar
Singh
2022MT11276 mt1221276@maths.iitd.ac.in 0.3
2 Market Research Aditya
Raj
2022MT61980 mt6221980@maths.iitd.ac.in 0.3
3 Documentation Aman Di-
vya
2022MT11293 mt1221293@maths.iitd.ac.in 0.7
4 Software-1 Ambhore
Soham
Bhaskar
2022EE11713 ee1221713@ee.iitd.ac.in 0.7
5 Market Research Ayush
Nayak
2022MT11958 mt1221958@maths.iitd.ac.in 0.5
6 Market Research Ayush
Raj
2022MT11944 mt1221944@maths.iitd.ac.in 0.5
7 Software-2 Devansh
Upad-
hyay
2022MT11931 mt1221931@maths.iitd.ac.in 0.4
8 Software-2 Dhruv
Chaurasiya
2022MT11172 mt1221172@maths.iitd.ac.in 0.7
9 Market Research Ishan
Bankal
2022EE31779 ee3221779@ee.iitd.ac.in 0.1
Table continues on the next page
Page 7 of 119
S.no Role Name Entry No Email I.F
10 Documentation Ishant
Yadav
2022MT11397 mt1221397@maths.iitd.ac.in 0.5
11 Software-2 Niraj
Agarwal
2022MT11921 mt1221921@maths.iitd.ac.in 0.4
12 Documentation Ojas
Sharma
2022EE31746 ee3221746@ee.iitd.ac.in 0.4
13 Software-2 Praveen
Lakhara
2022MT11280 mt1221280@maths.iitd.ac.in 0.4
14 Documentation Sachin
Hiren
Trivedi
2022EE11190 ee1221190@ee.iitd.ac.in 0.4
15 Market Research Shivang
Goyal
2022MT11269 mt1221269@maths.iitd.ac.in 0.5
16 Software-2 Sumit
Sonowal
2022MT11296 mt1221296@maths.iitd.ac.in 0.4
17 Software-2 Suneel
Masarapu
2022MT11942 mt1221942@maths.iitd.ac.in 0.7
18 Market Research Taru
Singhal
2022MT11922 mt1221922@maths.iitd.ac.in 0.5
19 Documentation Tatsam
Ranjan
Sharma
2022MT61969 mt6221969@maths.iitd.ac.in 0.4
Page 8 of 119
Contents
I. List of Tables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
II. List of Figures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
Glossary 17
1 Introduction 19
1.1 Denitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
1.2 Mind Map . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
1.3 Project Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
1.4 Problem Statement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
1.5 Abstract . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
1.6 Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
2 SWOT Analysis 30
2.1 Strengths . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
2.1.1 Real-Time Updates . . . . . . . . . . . . . . . . . . . . . . . . . . 30
2.1.2 Easily Reproducible . . . . . . . . . . . . . . . . . . . . . . . . . 30
2.1.3 Power Eciency . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
2.1.4 Low Maintenance . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
2.1.5 Scalability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
2.1.6 Accessibility . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
2.1.7 High Accuracy . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
2.1.8 Dual Power Supply . . . . . . . . . . . . . . . . . . . . . . . . . . 32
2.1.9 Compatibility with Existing Bus Systems . . . . . . . . . . . . . 32
2.1.10 Flashing Displays . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
2.1.11 Wi-Fi and BLE Integration . . . . . . . . . . . . . . . . . . . . . 33
2.1.12 Low-Cost Components . . . . . . . . . . . . . . . . . . . . . . . . 33
2.2 Weaknesses . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
2.2.1 Complex Integration . . . . . . . . . . . . . . . . . . . . . . . . . 33
2.2.2 Dependency on Solar Power . . . . . . . . . . . . . . . . . . . . . 33
2.2.3 False Detection of Human Presence . . . . . . . . . . . . . . . . . 34
2.2.4 Limited Data Rate . . . . . . . . . . . . . . . . . . . . . . . . . . 34
2.2.5 Dependency on Network Coverage . . . . . . . . . . . . . . . . . 34
2.2.6 Initial Cost . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
2.2.7 Installation Challenges . . . . . . . . . . . . . . . . . . . . . . . . 34
2.2.8 Maintenance Requirements . . . . . . . . . . . . . . . . . . . . . 35
2.2.9 Limited Range of PIR Sensors . . . . . . . . . . . . . . . . . . . . 35
2.2.10 Wi-Fi and LoRa Interference . . . . . . . . . . . . . . . . . . . . 35
Page 9 of 119
2.2.11 Manual Data Entry . . . . . . . . . . . . . . . . . . . . . . . . . . 35
2.2.12 Bus Congestion . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
2.2.13 Lack of Integration with Other Modes of Transport . . . . . . . . 36
2.2.14 ESP32 Microcontroller Limitations . . . . . . . . . . . . . . . . . 36
2.3 Opportunities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
2.3.1 Expansion into Smart City Initiatives . . . . . . . . . . . . . . . . 36
2.3.2 Data Analytics and Optimization . . . . . . . . . . . . . . . . . . 37
2.3.3 Partnerships with Technology Providers . . . . . . . . . . . . . . 37
2.3.4 Enhanced User Experience . . . . . . . . . . . . . . . . . . . . . . 37
2.3.5 Integration with Other Modes of Transport . . . . . . . . . . . . 38
2.3.6 Customization for Local Needs . . . . . . . . . . . . . . . . . . . 38
2.3.7 Private Bus Networks . . . . . . . . . . . . . . . . . . . . . . . . 38
2.3.8 Environmental Benets . . . . . . . . . . . . . . . . . . . . . . . 38
2.3.9 Integration with AI and Machine Learning . . . . . . . . . . . . . 39
2.3.10 Voice Assistance and Accessibility Features . . . . . . . . . . . . 39
2.4 Threats . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
2.4.1 Technological Obsolescence . . . . . . . . . . . . . . . . . . . . . 39
2.4.2 Cybersecurity Risks . . . . . . . . . . . . . . . . . . . . . . . . . 39
2.4.3 Regulatory Challenges . . . . . . . . . . . . . . . . . . . . . . . . 40
2.4.4 Competition from Alternative Transportation Solutions . . . . . . 40
2.4.5 Public Resistance . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
2.4.6 Extreme Weather Conditions . . . . . . . . . . . . . . . . . . . . 40
2.4.7 Vandalism and Theft . . . . . . . . . . . . . . . . . . . . . . . . . 40
2.4.8 Technical Expertise . . . . . . . . . . . . . . . . . . . . . . . . . . 41
2.4.9 Denial of Service Attacks . . . . . . . . . . . . . . . . . . . . . . 41
2.4.10 Economic Constraints . . . . . . . . . . . . . . . . . . . . . . . . 41
3 Design Improvements 42
3.1 Implementing Pseudo Stops and Creating a WiFi Mesh Network . . . . . 42
3.2 Utilizing OBD Ports for Enhanced Bus Monitoring . . . . . . . . . . . . 42
3.3 Increasing the Range of ESP32 for Robust Connectivity . . . . . . . . . 43
3.4 Establishing Line-of-Sight (Communication Using Pseudo Stops) . . . . . 44
3.5 Tracking Bus Capacity and Informing Waiting Passengers . . . . . . . . 44
3.6 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
4 Requirements 46
4.1 Microcontrollers and Communication Modules . . . . . . . . . . . . . . . 46
4.2 Sensor Components . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
4.3 Display Components . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
4.4 LED and Visual Indicators . . . . . . . . . . . . . . . . . . . . . . . . . . 47
4.5 Power and Energy Management . . . . . . . . . . . . . . . . . . . . . . . 47
4.6 Enclosures, Mounting, and Structural Materials . . . . . . . . . . . . . . 47
4.7 Feedback, Accessibility, and Interface Components . . . . . . . . . . . . . 48
4.8 Data Logging and Processing . . . . . . . . . . . . . . . . . . . . . . . . 48
4.9 System Operation Protocols . . . . . . . . . . . . . . . . . . . . . . . . . 48
4.9.1 Bus Operation Protocol . . . . . . . . . . . . . . . . . . . . . . . 48
4.9.2 Exception Handling Protocol . . . . . . . . . . . . . . . . . . . . 48
4.10 Connectivity and Scalability . . . . . . . . . . . . . . . . . . . . . . . . . 48
Page 10 of 119
4.11 Operational Hours . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
4.12 Stop Unit Detailed Specications . . . . . . . . . . . . . . . . . . . . . . 49
4.13 Bus-Mounted Unit Detailed Specications . . . . . . . . . . . . . . . . . 49
4.14 Miscellaneous Requirements and Data Collection . . . . . . . . . . . . . 49
4.15 System Survey and Analysis . . . . . . . . . . . . . . . . . . . . . . . . . 50
4.16 Requirements Table . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
5 Specications 51
5.1 Hardware Specications . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
5.1.1 Core Hardware: ESP32 . . . . . . . . . . . . . . . . . . . . . . . 51
5.1.2 Power Supply System . . . . . . . . . . . . . . . . . . . . . . . . 52
5.1.3 Display System . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
5.2 Software Specications . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
5.3 Performance Specications . . . . . . . . . . . . . . . . . . . . . . . . . . 54
5.4 Man-hour specications . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
5.4.1 Man-hours . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
5.4.2 Skillset . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
5.4.3 How Assignment was Done . . . . . . . . . . . . . . . . . . . . . 63
5.4.4 Surplus Manpower . . . . . . . . . . . . . . . . . . . . . . . . . . 63
6 Design 64
6.1 Bus Unit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
6.1.1 Bluetooth Module with ELM327 Interface . . . . . . . . . . . . . 64
6.1.2 Motion Processing Unit (MPU6050) . . . . . . . . . . . . . . . . 65
6.2 Bus Stop Unit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
6.2.1 Component Functions . . . . . . . . . . . . . . . . . . . . . . . . 66
6.2.2 Integration and Working Mechanism . . . . . . . . . . . . . . . . 66
6.3 Display Unit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
6.3.1 MAX7219 and Dot Matrix . . . . . . . . . . . . . . . . . . . . . . 66
6.3.2 Data and Control . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
6.4 Position Tracking Comparatives . . . . . . . . . . . . . . . . . . . . . . . 67
6.4.1 GPS using the Neo 6M Module . . . . . . . . . . . . . . . . . . . 67
6.4.2 Bus’s On-Board Diagnostics (OBD) . . . . . . . . . . . . . . . . . 68
6.4.3 MPU6050 Accelerometer/Gyroscope . . . . . . . . . . . . . . . . 68
6.4.4 RSSI‐Based Node Localization and Bus Tracking . . . . . . . . . 68
6.4.5 Comparison Table . . . . . . . . . . . . . . . . . . . . . . . . . . 69
6.4.6 Comparing Accuracy and Feasibility . . . . . . . . . . . . . . . . 69
6.4.7 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70
6.5 WiFi Mesh vs. BLE Mesh Comparatives . . . . . . . . . . . . . . . . . . 70
6.5.1 Comparison of WiFi Mesh and BLE Mesh . . . . . . . . . . . . . 70
6.5.2 Hybrid Approach: The Best of Both Worlds . . . . . . . . . . . . 71
6.5.3 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
6.6 Latency, Power, Connectivity, Cost, and Integration Comparatives . . . . 71
6.6.1 Latency Performance . . . . . . . . . . . . . . . . . . . . . . . . . 71
6.6.2 Power Eciency . . . . . . . . . . . . . . . . . . . . . . . . . . . 72
6.6.3 Connectivity and Environmental Robustness . . . . . . . . . . . . 72
6.6.4 Cost Considerations . . . . . . . . . . . . . . . . . . . . . . . . . 72
6.6.5 Integration and Feature Set . . . . . . . . . . . . . . . . . . . . . 73
Page 11 of 119
6.6.6 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73
6.7 Sensor Comparison . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73
6.7.1 Types of Gate Sensors . . . . . . . . . . . . . . . . . . . . . . . . 73
6.7.2 Cost Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74
6.7.3 Advantages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74
6.7.4 Disadvantages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74
6.7.5 Types of Weight Sensors . . . . . . . . . . . . . . . . . . . . . . . 74
6.7.6 Cost Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74
6.7.7 Advantages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74
6.7.8 Disadvantages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74
6.7.9 Final Comparison: Gate Sensor vs. Weight Sensor . . . . . . . . 75
6.7.10 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75
6.8 Network Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75
6.9 Control Flow Diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76
6.10 Arduino Code . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76
6.10.1 MPU6050 Sensor Integration . . . . . . . . . . . . . . . . . . . . 76
6.10.2 Dot Matrix Scrolling Display . . . . . . . . . . . . . . . . . . . . 78
6.10.3 OBD2 ELM327 Connecting Code . . . . . . . . . . . . . . . . . . 79
6.11 Hardware Prototyping . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82
7 Range Testing of ESP-NOW Communication 83
7.1 Setup Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83
7.2 Test Methodology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83
7.3 Distance Measurement . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84
7.4 Summary of Results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85
8 CAD Model Views of the Enclosure 87
Bibliography 89
A Document Statistics 90
B Softwares Used 91
C Document ID 93
D Minutes of the Meeting (MoMs) 94
D.1 Minutes of Meeting (MOMs) . . . . . . . . . . . . . . . . . . . . . . . . . 100
D.1.1 Software Subtribe . . . . . . . . . . . . . . . . . . . . . . . . . . 100
D.1.2 Market Research Subtribe . . . . . . . . . . . . . . . . . . . . . . 103
D.2 Mechanical Design and Ideation . . . . . . . . . . . . . . . . . . . . . . . 105
D.2.1 Attendees . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105
D.2.2 Agenda . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105
D.2.3 Discussion Points . . . . . . . . . . . . . . . . . . . . . . . . . . . 105
D.2.4 Resolutions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105
D.2.5 Action Items & Responsibilities . . . . . . . . . . . . . . . . . . . 106
D.3 Documentation Subtribe . . . . . . . . . . . . . . . . . . . . . . . . . . . 107
D.3.1 Attendees . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107
D.3.2 Agenda . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107
Page 12 of 119
D.3.3 Discussion Points . . . . . . . . . . . . . . . . . . . . . . . . . . . 108
D.3.4 Action Items & Responsibilities . . . . . . . . . . . . . . . . . . . 109
D.3.5 Next Steps . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109
D.4 Minutes of the Meeting (MoM) . . . . . . . . . . . . . . . . . . . . . . . 110
D.4.1 Attendees . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110
D.4.2 Agenda . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110
D.4.3 Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110
D.4.4 Resolutions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110
D.4.5 Action Items & Responsibilities . . . . . . . . . . . . . . . . . . . 110
D.4.6 Action Taken . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110
E Minutes of Meeting(Week 3) 111
E.1 Software Subtribe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111
E.1.1 Meeting Details . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111
E.1.2 Attendees . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111
E.1.3 Agenda . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112
E.1.4 Discussion Points . . . . . . . . . . . . . . . . . . . . . . . . . . . 112
E.1.5 Resolutions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112
E.1.6 Action Items & Responsibilities . . . . . . . . . . . . . . . . . . . 112
E.1.7 Next Steps . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112
E.2 Market Research Subtribe . . . . . . . . . . . . . . . . . . . . . . . . . . 112
E.2.1 Meeting Details . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112
E.2.2 Attendees . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113
E.2.3 Agenda . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113
E.2.4 Discussion Points . . . . . . . . . . . . . . . . . . . . . . . . . . . 113
E.2.5 Resolutions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113
E.2.6 Action Items & Responsibilities . . . . . . . . . . . . . . . . . . . 113
E.2.7 Next Steps . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113
E.3 Mechanical Design and Ideation . . . . . . . . . . . . . . . . . . . . . . . 114
E.3.1 Meeting Details . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114
E.3.2 Attendees . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114
E.3.3 Agenda . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114
E.3.4 Discussion Points . . . . . . . . . . . . . . . . . . . . . . . . . . . 114
E.3.5 Resolutions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114
E.3.6 Action Items & Responsibilities . . . . . . . . . . . . . . . . . . . 115
E.3.7 Next Steps . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115
E.4 Documentation Subtribe . . . . . . . . . . . . . . . . . . . . . . . . . . . 115
E.4.1 Meeting Details . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115
E.4.2 Attendees . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115
E.4.3 Agenda . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 116
E.4.4 Discussion Points . . . . . . . . . . . . . . . . . . . . . . . . . . . 117
E.4.5 Resolutions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117
E.4.6 Action Items & Responsibilities . . . . . . . . . . . . . . . . . . . 118
E.4.7 Next Steps . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118
E.5 Progress Review Meeting . . . . . . . . . . . . . . . . . . . . . . . . . . . 119
E.5.1 Meeting Details . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119
E.5.2 Attendees . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119
E.5.3 Agenda . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119
Page 13 of 119
E.5.4 Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119
E.5.5 Resolutions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119
E.5.6 Action Items & Responsibilities . . . . . . . . . . . . . . . . . . . 119
E.5.7 Action Taken . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119
Page 14 of 119
I. List of Tables
1 Single Point of Contact(SPOC) . . . . . . . . . . . . . . . . . . . . . . . 1
2 List of Participants . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
3 List of Participants with IF <1 . . . . . . . . . . . . . . . . . . . . . . . 7
5.1 Man-hours invested . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
5.2 Skillset acquired . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
6.1 Comparison of Position Tracking Methods . . . . . . . . . . . . . . . . . 69
6.2 Comparison between Gate Sensor and Weight Sensor . . . . . . . . . . . 75
Page 15 of 119
II. List of Figures
1.1 Mind Map of the Project . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
1.2 Network chart from Project Libre. . . . . . . . . . . . . . . . . . . . . . . 22
1.3 Network chart from Project Libre. . . . . . . . . . . . . . . . . . . . . . . 22
1.4 Network chart from Project Libre. . . . . . . . . . . . . . . . . . . . . . . 23
1.5 Network chart from Project Libre. . . . . . . . . . . . . . . . . . . . . . . 23
1.6 Project Timeline in Gantt Chart . . . . . . . . . . . . . . . . . . . . . . 24
1.7 Resource Breakdown, generated from ProjectLibre . . . . . . . . . . . . . 25
1.8 Resource Breakdown, generated from ProjectLibre . . . . . . . . . . . . . 26
1.9 Resource Breakdown, generated from ProjectLibre . . . . . . . . . . . . . 27
6.1 A prototype of the bus unit . . . . . . . . . . . . . . . . . . . . . . . . . 64
6.2 Separator Port of OBD2 . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
6.3 MPU6050 connected with ESP32 . . . . . . . . . . . . . . . . . . . . . . 65
6.4 Network Graph for 2 Buses and 2 Stops . . . . . . . . . . . . . . . . . . 75
6.5 Flowchart of the OBD Data Processing System . . . . . . . . . . . . . . 76
6.6 Your caption here . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78
6.7 Simulating Dot matrix display . . . . . . . . . . . . . . . . . . . . . . . . 79
6.8 Design of box . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82
6.9 Design of cover . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82
7.1 Transmitting ESP32 setup at a xed point near the Computer Science
Department . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83
7.2 Extended path covering a distance of 0.33 km . . . . . . . . . . . . . . . 84
7.3 Range test path near IIT Delhi Main Road (0.08 km) . . . . . . . . . . . 85
7.4 Overall path view for range testing at IIT Delhi . . . . . . . . . . . . . . 86
8.1 Top View - Lid . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87
8.2 Top View - Box . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87
8.3 Side View - Lid . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87
8.4 Isometric View - Box . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87
8.5 Front View - Box . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88
8.6 Top View - Box Inner . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88
8.7 Side View - Box . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88
8.8 Front View - Box Inner . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88
8.9 Isometric View - Lid . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88
Page 16 of 119
Glossary
ADC (Analog-to-Digital Converter) . 16, 51
BLE (Bluetooth Low Energy) . 16, 19, 20, 33
DAC (Digital-to-Analog Converter) . 16, 51
ESP32 . 16, 19, 30–33, 36, 37, 46, 51, 52
ESP8266 SoC . 16, 20, 51
GPIO (General Purpose Input/Output) . 16, 51, 53
I2C (Inter-Integrated Circuit) . 16, 51, 53
LCD (Liquid Crystal Display) . 16, 19, 53
LoRa Protocol Module . 16, 20, 46
LoRaWAN (Long Range Wide Area Network) . 16, 19, 32–34, 37, 39
LOS (Line of Sight) . 16, 19, 44, 45
mmWave radar . 16, 19, 32–34
PIR (Passive Infrared Sensor) . 16, 20, 33–35, 46
PWM (Pulse Width Modulation) . 16, 31, 48, 51
RTC (Real-Time Clock) . 16, 20, 48
Page 17 of 119
1. Introduction
1.1 Denitions
ESP32 A low-power system-on-chip (SoC) microcontroller with integrated Wi-Fi and
Bluetooth, commonly used in IoT applications.
LoRa communication modules Wireless communication modules that use Long Range
(LoRa) technology for low-power, long-distance data transmission.
LCD (Liquid Crystal Display) A Liquid Crystal Display (LCD (Liquid Crystal Dis-
play)) that presents visual information on electronic devices.
PWM outputs Pulse Width Modulation (PWM) outputs allow for controlling the
power delivered to electronic components like LEDs and motors.
mmWave radar A high-frequency radar system (typically 24 GHz or 77 GHz) used for
object detection, motion sensing, and ranging applications.
LoRaWAN (Long Range Wide Area Network) A networking protocol built on LoRa
technology that enables low-power, wide-area networking for IoT devices.
BLE (Bluetooth Low Energy) Bluetooth Low Energy (BLE), a wireless communica-
tion technology optimized for low-power, short-range communication.
IoT devices Internet of Things (IoT) devices are interconnected smart objects that
collect, process, and transmit data over a network.
MPU6050 accelerometer A motion-sensing device integrating a 3-axis gyroscope and
a 3-axis accelerometer.
Denial of service A cybersecurity attack that disrupts normal trac by overwhelming
a network, service, or device with excessive requests.
Localized WiFi mesh network A decentralized network topology where multiple Wi-
Fi nodes communicate with each other without requiring a central access point.
On-Board Diagnostics A vehicle’s self-diagnostic system that monitors performance
and emissions-related components.
Line-of-Sight (LOS (Line of Sight)) A direct, unobstructed path between a trans-
mitter and receiver in wireless communication.
Capacity planning The process of determining the resources required to meet future
system demands eectively.
Page 19 of 119
Dash7 Protocol Module A wireless communication module using Dash7, a low-power,
long-range networking protocol for IoT applications.
LoRa Protocol Module A module implementing LoRa protocol, enabling long-range,
low-power wireless communication.
BLE (Bluetooth Low Energy) A hardware module that facilitates Bluetooth Low
Energy (BLE) communication.
MMA845xQ Digital Accelerometer A family of low-power, high-resolution digital
accelerometers for motion detection and orientation sensing.
Passenger Detection Sensor A sensor used to detect the presence of passengers in
vehicles or public transportation systems.
MRU (Bus Accelerometer) A Motion Reference Unit (MRU) used in buses to mea-
sure acceleration and movement parameters.
8x8 Dot Matrix Display A display module consisting of an 8x8 grid of LEDs for al-
phanumeric and graphical representation.
IP67-Rated Enclosures Enclosures rated IP67 are dust-tight and can withstand tem-
porary immersion in water.
Fresnel Lens A compact, lightweight lens that enhances light collection and focusing
eciency.
Verro Board A perforated board used for prototyping electronic circuits.
Burge Strip A component used for electrical connections in prototyping boards.
Mechanical Fixation Brackets Structural components used to secure electronic de-
vices in place.
Real-Time Clock (RTC (Real-Time Clock)) Module A module that provides ac-
curate timekeeping functionality, even when a system is powered o.
UART (Universal Asynchronous Receiver-Transmitter) A serial communication
protocol used for data exchange between devices without requiring a clock signal.
ESP8266 SoC A low-cost Wi-Fi-enabled microcontroller system-on-chip (SoC) widely
used in IoT applications.
Xtensa LX6 Microprocessor A dual-core microprocessor architecture developed by
Tensilica and used in ESP32 chips.
Gantt chart A type of bar chart used in project management to represent a project
schedule, showing the start and end dates of individual tasks.
7-segment LCD A display module consisting of seven segments arranged to display
numerical digits and limited characters, commonly used in digital clocks and coun-
ters.
PIR (Passive Infrared Sensor) sensor A Passive Infrared (PIR (Passive Infrared Sen-
sor)) sensor that detects motion by sensing infrared radiation changes, often used
in security and automation systems.
Page 20 of 119
LoRa A long-range, low-power wireless communication technology based on spread spec-
trum modulation, used in wide-area IoT networks.
NEXTBUS A real-time public transportation tracking system that predicts vehicle
arrival times using GPS and wireless data.
PlatformIO An open-source IoT development platform supporting multiple microcon-
trollers and frameworks, integrated with modern IDEs for easier embedded devel-
opment.
Thonny A beginner-friendly Python IDE often used for microcontroller programming
and teaching, known for its simple interface and debugger.
1.2 Mind Map
Figure 1.1: Mind Map of the Project
Page 21 of 119
1.3 Project Management
The outputs from ProjectLibre include the Gantt chart (Fig. 1.6), network charts
(Figs. 1.3), and resource breakdown (Fig. 1.7), each playing a crucial role in project
planning and execution.
The Gantt chart (Fig. 1.6) provides a timeline-based view of tasks, detailing their start
and nish dates, durations, and dependencies. It aids in tracking progress, managing
resources, and identifying potential bottlenecks.
The network charts (Figs.1.2 to 1.5 ) focus on task dependencies and workow, high-
lighting their sequence and identifying the critical path, which determines the shortest
completion time. Together, these charts enhance project visibility, streamline coordina-
tion, and ensure timely execution.
The resource breakdown (Figs.1.7 to1.9 ) ensures clear task allocation, preventing
workload imbalances and delays. By dening team roles, responsibilities, and timelines,
it optimizes eciency, improves coordination, and enhances accountability, ensuring a
smooth and conict-free workow.
Figure 1.2: Network chart from Project Libre.
Figure 1.3: Network chart from Project Libre.
Page 22 of 119
1.4 Problem Statement
A campus bus service is provided to transport residents between two endpoints: the East
Campus Market and the DMS TIFAC Building. The service operates with a variable
number of buses (ranging from 0 to k, with k = 2 at present). Since the buses do not
display their labels, users must wait at the appropriate bus stop on the correct side of
the street and board the next bus traveling in their desired direction. When multiple
buses are available, they start with staggered departure times. Travel times between
stops are approximate and may vary by up to one minute. In essence, the buses operate
on a circular route turning around at the endpoints and returning along the same roads
with a mandated waiting period of ve minutes at each endpoint before commencing the
return journey.
1.5 Abstract
Project P2 NEXTBUS aims to enhance the campus bus service by providing real-time
information on bus arrivals at each bus stop. The system is designed to inform wait-
ing users through dedicated display units—of the expected time (in minutes) until the
next bus arrives, enabling them to decide whether to wait or seek alternative transporta-
tion. The display units are engineered to alternate messages in both English and Hindi,
ensuring clear communication for a diverse user base. Key features include:
1. Accurate prediction of bus arrival times with a tolerance of ±1 minute.
2. Readable display interfaces that meet stringent visibility requirements.
3. Integration with robust power management and connectivity options to ensure con-
tinuous operation, even under adverse weather conditions.
4. Support for long range communication with clear line-of-sight to maintain reliable
data transfer between units.
The NEXTBUS system is intended to streamline campus transportation by reducing
uncertainty in waiting times and improving overall service eciency.
1.6 Motivation
Timely and reliable information about bus arrival times is critical for the daily commuters
on campus. The primary motivation behind Project P2 NEXTBUS is to address the
uncertainty faced by waiting passengers, who currently have no indication of when the
next bus will arrive. By providing real-time updates through strategically installed display
units, the system empowers users to make informed decisions—whether to wait, walk,
or opt for alternative transport. Furthermore, the project considers practical constraints
such as:
• The need for a robust and weather-resistant design to withstand Delhi’s diverse
climatic conditions.
• The importance of power eciency, with provisions for battery operation and op-
tional solar power, ensuring functionality from 0700 to 1930 hours.
Page 28 of 119
• Seamless integration of connectivity options (e.g., WiFi for over-the-air updates
and Bluetooth for inter-device communication) without over-dependence on cellular
networks.
• Emphasis on long range and line-of-sight communication to guarantee reliable, un-
interrupted transmission of information between the bus and display units.
Overall, NEXTBUS is envisioned as an aordable, reliable solution that not only im-
proves the user experience but also aids the campus Transport Section in monitoring and
maintaining the bus service eectively.
Page 29 of 119
2. SWOT Analysis
The SWOT analysis of the NEXTBUS project( Previous year best project) evaluates its
key strengths, weaknesses, opportunities, and threats, providing a structured overview of
its viability and potential challenges.
2.1 Strengths
2.1.1 Real-Time Updates
1. Empowering Commuters: The system provides real-time updates on bus arrival
times, which empowers commuters to make informed decisions and reduces uncer-
tainty. This feature is particularly benecial in urban areas where trac conditions
can change rapidly, leading to unpredictable bus schedules. By providing accurate
and up-to-date information, the system helps commuters plan their journeys more
eectively, reducing waiting times and improving overall satisfaction.
2. Encouraging Public Transport Use: By reducing the uncertainty associated
with bus schedules, the system can encourage more people to use public trans-
portation. This is particularly important in cities where trac congestion and air
pollution are major concerns. Increased use of public transportation can lead to
reduced emissions and a lower environmental footprint.
3. Dynamic Adjustments: The system can dynamically adjust bus schedules based
on real-time data, such as trac conditions, bus breakdowns, or delays. This en-
sures that commuters are always informed of the latest changes, reducing frustration
and improving the overall reliability of the bus service.
2.1.2 Easily Reproducible
1. Fast and Cost-Eective Reproducibility: The design focuses on fast and cost-
eective reproducibility, which is crucial for scaling the system to a larger network.
The use of modular components, such as the ESP32 microcontroller and WiFi
communication modules, allows for easy replication and deployment across multiple
bus stops and buses. This scalability is essential for expanding the system to cover
larger areas or more routes.
2. Minimal Infrastructure Changes: The system can easily accommodate addi-
tional buses or stops without signicant infrastructure changes. This is particularly
important in cities where space is limited, and infrastructure upgrades can be costly
and time-consuming.
Page 30 of 119
2.1.3 Power Eciency
1. Solar Power Integration: The system is designed to be power-ecient, with
solar panels as an optional backup. This reduces operational costs and environ-
mental impact, making the system more sustainable. Solar power is particularly
useful in areas with unreliable electricity supply, ensuring that the system remains
operational even during power outages.
2. Low Power Consumption: Components like the ESP32 microcontroller and
LoRa communication modules are designed for low power consumption, making the
system energy-ecient and suitable for long-term operation. This is particularly
important in remote or rural areas where access to electricity may be limited.
2.1.4 Low Maintenance
1. Durable Design: The system is designed to be durable and low-maintenance,
which is essential for long-term operation in harsh weather conditions. The use of
weatherproof enclosures and robust materials ensures that the system can withstand
extreme temperatures, rain, and other environmental factors.
2. Reduced Operational Costs: The low-maintenance design reduces the need for
frequent repairs or replacements, lowering operational costs and ensuring that the
system remains reliable over time.
2.1.5 Scalability
1. Modular Design: The system is designed to be modular, allowing for easy addi-
tion of new bus stops or buses. This scalability is crucial for expanding the system
to cover larger areas or more routes. The use of standardized components, such
as the ESP32 microcontroller and LoRa communication modules, ensures that the
system can be easily scaled up or down as needed.
2. Flexibility: The system can be adapted to dierent environments and require-
ments, making it suitable for both urban and rural areas. This exibility is partic-
ularly important in cities with diverse transportation needs, where the system may
need to be customized to meet specic requirements.
2.1.6 Accessibility
1. Multilingual Support: The system uses 7-segment LCD with multilingual sup-
port (English and Hindi), making it accessible to a wider audience. This is partic-
ularly important in multicultural cities where multiple languages are spoken.
2. Inclusive Design: The system includes auditory and tactile feedback mechanisms,
such as PWM (Pulse Width Modulation) outputs or speech ICs, ensuring that
visually impaired passengers can also benet from the system. This inclusive design
ensures that the system is accessible to all commuters, regardless of their physical
abilities.
Page 31 of 119
2.1.7 High Accuracy
1. Advanced Technologies: The project incorporates advanced technologies like
mmWave radar, LoRaWAN (Long Range Wide Area Network), and ESP32 micro-
controllers, which enhance the system’s accuracy and reliability. mmWave radar
can detect human presence with high accuracy, even in challenging weather con-
ditions or crowded situations. LoRaWAN (Long Range Wide Area Network) can
transmit data over several kilometers, making it ideal for communication between
buses and stops.
2. Precision in Detection: The use of mmWave radar ensures that the system can
accurately detect human presence, reducing the likelihood of false positives. This
is particularly important in crowded bus stops where multiple passengers may be
waiting.
2.1.8 Dual Power Supply
1. Continuous Operation: The unit is powered by both the bus’s battery and an
internal battery, ensuring continuous operation. This dual power supply ensures
that the system remains operational even if one power source fails, reducing the
risk of downtime.
2. Redundancy: The use of dual power sources provides redundancy, ensuring that
the system remains operational in the event of a power failure. This is particularly
important in areas with unreliable electricity supply.
2.1.9 Compatibility with Existing Bus Systems
1. Seamless Integration: The system is designed to integrate seamlessly with ex-
isting bus systems, minimizing the need for costly infrastructure upgrades. This
compatibility ensures that the system can be easily adopted by existing bus net-
works, reducing the time and cost of deployment.
2. Minimal Disruption: The system can be installed on existing bus stop poles
or signboards, reducing installation time and costs. This minimizes disruption to
existing bus services, ensuring that commuters are not inconvenienced during the
installation process.
2.1.10 Flashing Displays
1. Improved Visibility: The ashing displays for the current time (±1 minute accu-
racy) ensure that users can quickly and easily read the information, even in bright
sunlight. This improves the overall user experience, ensuring that commuters can
access the information they need without diculty.
2. Enhanced Readability: The use of ashing displays ensures that the information
is easily readable, even from a distance. This is particularly important in crowded
bus stops where multiple passengers may be trying to access the information simul-
taneously.
Page 32 of 119
2.1.11 Wi-Fi and BLE Integration
1. Flexibility and Redundancy: The system integrates Wi-Fi and Bluetooth Low
Energy (BLE (Bluetooth Low Energy)) for short-range communication, providing
exibility and redundancy in case of LoRa network failures. This ensures that the
system remains operational even if one communication method fails, reducing the
risk of downtime.
2. Enhanced Connectivity: The integration of Wi-Fi and BLE (Bluetooth Low
Energy) ensures that the system can communicate with a wide range of devices,
including smartphones and other IoT devices. This enhances the overall function-
ality of the system, providing commuters with more options for accessing real-time
information.
2.1.12 Low-Cost Components
1. Cost-Eective Design: The system uses cost-eective components like the ESP32
microcontroller, MPU6050 accelerometer, and PIR (Passive Infrared Sensor) sen-
sors, which are readily available and aordable. This reduces the overall cost of the
system, making it more accessible to cities with limited budgets.
2. Aordable Maintenance: The use of low-cost components ensures that mainte-
nance and replacement costs are kept to a minimum, reducing the overall opera-
tional costs of the system.
2.2 Weaknesses
2.2.1 Complex Integration
1. Challenges in Integration: Integrating multiple technologies (e.g., mmWave
radar, LoRaWAN (Long Range Wide Area Network), ESP32) into a cohesive sys-
tem may be challenging. Each technology has its own set of requirements and
limitations, and ensuring that they work together seamlessly can be dicult.
2. Technical Expertise Required: The integration of multiple technologies requires
a high level of technical expertise, which may not be readily available in all locations.
This could increase the complexity and cost of deployment.
2.2.2 Dependency on Solar Power
1. Limited Sunlight: While solar power is a backup, the system’s reliance on it in
areas with limited sunlight (e.g., shaded bus stops) could be a limitation. This
could lead to power shortages, especially during cloudy days or in areas with heavy
tree cover.
2. Battery Backup Limitations: The system relies on batteries for continuous
operation, and managing battery life, especially in high-usage scenarios, could be a
challenge. Frequent battery replacements or recharging could increase maintenance
costs.
Page 33 of 119
2.2.3 False Detection of Human Presence
1. PIR (Passive Infrared Sensor) Sensor Limitations: The system may report
false positives in passenger detection, especially with PIR (Passive Infrared Sensor)
sensors, which can be triggered by pets or other heat sources. This could lead to
inaccurate passenger counts and reduce the overall reliability of the system.
2. Limited Range: PIR (Passive Infrared Sensor) sensors have a limited detection
range, which may not be sucient for larger bus stops or areas with high passenger
volumes. This could lead to missed detections and reduce the accuracy of the
system.
2.2.4 Limited Data Rate
1. LoRaWAN (Long Range Wide Area Network) Limitations: LoRaWAN
(Long Range Wide Area Network) has a low data rate, which may limit the amount
of information that can be transmitted in real-time. This could be a limitation in
areas where large amounts of data need to be transmitted quickly, such as in densely
populated urban areas.
2. Network Congestion: In densely populated areas, the system may experience
network congestion, leading to delays in data transmission and reduced perfor-
mance. This could reduce the overall reliability of the system and lead to inaccurate
information being displayed to passengers.
2.2.5 Dependency on Network Coverage
1. WiFi and LoRa Coverage: The system relies on WiFi and LoRaWAN (Long
Range Wide Area Network) networks, which may not be available in all areas.
This could limit the system’s eectiveness in remote or rural areas where network
coverage is limited.
2. Interference: In areas with high WiFi or LoRa usage, there may be interference
that could disrupt communication between buses and bus stops. This could lead
to delays in information dissemination and reduced system reliability.
2.2.6 Initial Cost
1. High Initial Investment: The installation of solar panels and batteries involves
a high initial investment. This could be a barrier for cities with limited budgets,
particularly in developing countries where funding for public transportation infras-
tructure may be limited.
2. Cost of Advanced Components: The mmWave radar used for detecting human
presence is relatively expensive (Rs. 3250), which could increase the overall cost of
the system, especially when scaling up to multiple bus stops.
2.2.7 Installation Challenges
1. Specialized Skills Required: The installation of solar panels, sensors, and com-
munication modules may require specialized skills and equipment, increasing the
Page 34 of 119
complexity and cost of deployment. This could be a challenge in areas where tech-
nical expertise is limited.
2. Time-Consuming Installation: The installation process may be time-consuming,
particularly in areas with limited infrastructure. This could delay the deployment
of the system and reduce its overall eectiveness.
2.2.8 Maintenance Requirements
1. Regular Maintenance: Regular maintenance of solar panels, sensors, and com-
munication modules is necessary to ensure optimal performance. This could lead to
increased operational costs and potential downtime if maintenance is not performed
regularly.
2. Battery Management: Managing battery life, especially in high-usage scenarios,
could be a challenge. Frequent battery replacements or recharging could increase
maintenance costs and reduce the overall reliability of the system.
2.2.9 Limited Range of PIR Sensors
1. Detection Range: PIR (Passive Infrared Sensor) sensors have a limited detection
range, which may not be sucient for larger bus stops or areas with high passenger
volumes. This could lead to missed detections and reduce the accuracy of the
system.
2. False Positives: PIR (Passive Infrared Sensor) sensors can produce false positives,
such as detecting animals or other heat sources. This could lead to inaccurate
passenger counts and reduce the overall reliability of the system.
2.2.10 Wi-Fi and LoRa Interference
1. Interference Issues: In areas with high WiFi or LoRa usage, there may be inter-
ference that could disrupt communication between buses and bus stops. This could
lead to delays in information dissemination and reduced system reliability.
2. Network Congestion: In densely populated areas, the system may experience
network congestion, leading to delays in data transmission and reduced perfor-
mance. This could reduce the overall reliability of the system and lead to inaccurate
information being displayed to passengers.
2.2.11 Manual Data Entry
1. Potential for Errors: The system relies on accurate data input, such as bus stop
IDs and route information. Any errors in manual data entry could lead to incorrect
information being displayed to passengers. This could reduce the overall reliability
of the system and lead to confusion among commuters.
2. Data Management: Managing and updating the data manually could be time-
consuming and prone to errors. This could increase the complexity of the system
and reduce its overall eectiveness.
Page 35 of 119
2.2.12 Bus Congestion
1. Delays in Updates: In areas with high bus trac, the system may experience
delays in updating bus arrival times, leading to reduced accuracy and reliability.
This could reduce the overall eectiveness of the system and lead to frustration
among commuters.
2. Network Overload: High bus trac could lead to network overload, causing
delays in data transmission and reducing the system’s performance. This could
reduce the overall reliability of the system and lead to inaccurate information being
displayed to passengers.
2.2.13 Lack of Integration with Other Modes of Transport
1. Limited Scope: The system is primarily designed for bus networks and may not
integrate seamlessly with other modes of transport, such as trains or metro systems.
This could limit its eectiveness in multi-modal transport networks.
2. Fragmented Information: Without integration with other modes of transport,
commuters may receive fragmented information, reducing the overall eectiveness
of the system. This could lead to confusion and reduce the overall user experience.
2.2.14 ESP32 Microcontroller Limitations
1. Processing Power: While the ESP32 is cost-eective, it has limited processing
power compared to more advanced microcontrollers, which could be a constraint
in more complex applications. This could limit the system’s ability to handle large
amounts of data or perform complex calculations.
2. Memory Constraints: The ESP32 has limited memory, which could be a con-
straint in applications that require large amounts of data storage or processing.
This could reduce the overall functionality of the system and limit its ability to
handle complex tasks.
2.3 Opportunities
2.3.1 Expansion into Smart City Initiatives
1. Integration with Smart Trac Management: The NEXTBUS system could
be integrated into broader smart city initiatives, such as smart trac management
systems. This could enhance the overall eciency of urban transportation systems
and reduce trac congestion. For example, real-time data from the NEXTBUS sys-
tem could be used to optimize trac light timings, reducing delays and improving
trac ow.
2. Public Transportation Networks: The system could be integrated into public
transportation networks, providing real-time updates for buses, trams, and other
modes of transport. This would create a more comprehensive public transportation
information system, improving the overall user experience and encouraging more
people to use public transport.
Page 36 of 119
2.3.2 Data Analytics and Optimization
1. Predictive Analytics: The data collected by the system can be used for predictive
analytics, such as forecasting bus arrival times based on historical data or predicting
peak demand periods. This could help bus operators optimize their schedules and
reduce waiting times for commuters.
2. Route Optimization: The system can be used to optimize bus routes based on
real-time data, reducing travel times and improving overall eciency. For example,
the system could identify areas with high demand and adjust bus routes to better
serve those areas.
3. Performance Monitoring: The unit could also collect data on bus performance
(e.g., fuel eciency, maintenance needs) for further analysis. This could help bus
operators identify areas for improvement and reduce operational costs.
2.3.3 Partnerships with Technology Providers
1. Collaboration with LoRaWAN (Long Range Wide Area Network) and
ESP32 Manufacturers: Collaborating with technology providers (e.g., LoRaWAN
(Long Range Wide Area Network), ESP32 manufacturers) could lead to further in-
novation and cost reductions. This could result in more advanced features and
lower operational costs. For example, partnerships with technology providers could
lead to the development of more ecient communication modules or more powerful
microcontrollers.
2. Integration with Advanced Features: The unit could be expanded to include
features like route optimization, driver assistance, or predictive maintenance. This
could enhance the overall functionality of the system and improve the user experi-
ence.
2.3.4 Enhanced User Experience
1. Mobile App Integration: The system could be expanded to provide real-time
updates via mobile apps, increasing accessibility for tech-savvy users. This would
allow commuters to access real-time information on their smartphones, reducing
the need to rely on physical display units.
2. Voice Assistance: The system could be enhanced with voice assistance features,
allowing visually impaired passengers to receive real-time updates through audio
cues. This would improve the overall accessibility of the system and ensure that all
commuters can benet from its features.
3. Push Notications: The system could send push notications to users, alerting
them of delays, route changes, or other important information. This would improve
the overall user experience and ensure that commuters are always informed of the
latest changes.
Page 37 of 119
2.3.5 Integration with Other Modes of Transport
1. Multi-Modal Transportation: The system can be adapted to provide real-time
information for other modes of transportation, such as trains, trams, or ferries.
This would create a more comprehensive public transportation information system,
improving the overall user experience and encouraging more people to use public
transport.
2. Seamless Transitions: The system could be integrated with ride-sharing services,
providing commuters with a seamless transition between dierent modes of trans-
portation. This would improve the overall eciency of the transportation network
and reduce the need for private vehicles.
2.3.6 Customization for Local Needs
1. Language Support: The system could be customized to meet the specic needs
of dierent regions, such as language support, local transport regulations, and en-
vironmental conditions. This would ensure that the system is accessible to all
commuters, regardless of their location or language.
2. Local Regulations: The system could be adapted to comply with local transport
regulations, ensuring that it meets the specic requirements of dierent regions.
This would reduce the risk of regulatory challenges and ensure that the system can
be easily adopted in dierent locations.
2.3.7 Private Bus Networks
1. Adoption by Private Operators: The system could be adopted by private bus
operators, providing real-time information to passengers and improving the overall
quality of service. This would enhance the overall eciency of private bus networks
and improve the user experience for commuters.
2. Competitive Advantage: Private bus operators that adopt the NEXTBUS sys-
tem could gain a competitive advantage over those that do not, as they would be
able to provide a more reliable and ecient service to their passengers.
2.3.8 Environmental Benets
1. Reduced Carbon Emissions: By improving the eciency of bus operations and
reducing waiting times, the system can contribute to lower carbon emissions and a
reduced environmental footprint. This is particularly important in cities where air
pollution is a major concern.
2. Promotion of Public Transport: The system could encourage more people to
use public transportation, reducing the number of private vehicles on the road and
further contributing to environmental sustainability. This would help cities achieve
their climate goals and reduce their overall environmental impact.
Page 38 of 119
2.3.9 Integration with AI and Machine Learning
1. Improved Passenger Detection: Machine learning algorithms could be used to
improve the accuracy of passenger detection and reduce false positives. This would
enhance the overall reliability of the system and ensure that commuters receive
accurate information.
2. Predictive Maintenance: AI could be used to predict maintenance needs, reduc-
ing downtime and improving the overall eciency of the bus network. This would
help bus operators identify potential issues before they become major problems,
reducing the need for costly repairs.
2.3.10 Voice Assistance and Accessibility Features
1. Enhanced Accessibility: The system could be enhanced with voice assistance
features, allowing visually impaired passengers to receive real-time updates through
audio cues. This would improve the overall accessibility of the system and ensure
that all commuters can benet from its features.
2. Inclusive Design: The system could be designed to be more inclusive, ensuring
that it is accessible to all commuters, regardless of their physical abilities. This
would improve the overall user experience and ensure that the system is accessible
to a wider audience.
2.4 Threats
2.4.1 Technological Obsolescence
1. Rapid Advancements: Rapid advancements in technology could render some
components of the system obsolete, requiring frequent updates or replacements.
This could increase maintenance costs and require continuous investment in new
technologies.
2. Competition from New Systems: Other companies or organizations could de-
velop more advanced or cost-eective systems, posing a threat to the adoption and
success of the NEXTBUS system. This could reduce the overall market share of
the system and limit its impact.
2.4.2 Cybersecurity Risks
1. Vulnerability to Cyberattacks: The system relies on wireless communication
(WiFi, LoRaWAN (Long Range Wide Area Network)), which could be vulnerable
to cyberattacks or data breaches. This could compromise the system’s reliability
and lead to potential safety risks for passengers.
2. Data Privacy Concerns: The system collects and stores data on passenger counts
and bus movements, which could be subject to data privacy regulations. Compli-
ance with these regulations could increase the complexity and cost of the system.
Page 39 of 119
2.4.3 Regulatory Challenges
1. Compliance with Local Regulations: Implementing the system, especially the
use of radar technology, may require compliance with local regulations, which could
vary across dierent regions or countries. This could lead to delays in deployment
or additional costs for regulatory compliance.
2. Licensing and Permits: Obtaining the necessary licenses and permits for in-
stalling solar panels, communication modules, and other components could be time-
consuming and costly. This could delay the deployment of the system and reduce
its overall eectiveness.
2.4.4 Competition from Alternative Transportation Solutions
1. Ride-Sharing Apps: The rise of alternative transportation solutions, such as
ride-sharing apps or electric scooters, could reduce the demand for bus services.
This could limit the system’s adoption and reduce its overall impact.
2. Private Vehicles: The availability of aordable private vehicles could reduce the
demand for public transportation, limiting the system’s eectiveness. This could
reduce the overall ridership of buses and limit the system’s impact.
2.4.5 Public Resistance
1. Resistance to Change: Some users may resist adopting new technology, espe-
cially if they are accustomed to traditional bus schedules. This could slow down
the adoption and eectiveness of the system.
2. Digital Divide: In areas with low digital literacy or limited access to smart-
phones, the system may not be as eective, as commuters may not be able to fully
utilize its features. This could reduce the overall impact of the system and limit its
eectiveness.
2.4.6 Extreme Weather Conditions
1. Impact on Performance: Extreme weather conditions, such as heavy rain, snow,
or high temperatures, could aect the performance of the system’s components,
leading to reduced reliability. This could reduce the overall eectiveness of the
system and lead to frustration among commuters.
2. Damage to Infrastructure: Natural disasters, such as earthquakes or oods,
could damage the system’s infrastructure, leading to system downtime and in-
creased repair costs. This could reduce the overall reliability of the system and
limit its eectiveness.
2.4.7 Vandalism and Theft
1. Vulnerability to Vandalism: The display units and other components could be
vulnerable to vandalism or theft, especially in areas with high crime rates. This
could reduce the overall reliability of the system and lead to increased maintenance
costs.
Page 40 of 119
2. Security Measures: Implementing security measures to protect the system from
vandalism or theft could increase the overall cost of the system. This could reduce
the overall aordability of the system and limit its adoption.
2.4.8 Technical Expertise
1. Specialized Skills Required: The system may require specialized technical ex-
pertise for installation, maintenance, and troubleshooting, which could be dicult
to nd in certain regions. This could increase the complexity and cost of deploy-
ment.
2. Training Requirements: Training sta to operate and maintain the system could
be time-consuming and costly. This could reduce the overall eciency of the system
and limit its eectiveness.
2.4.9 Denial of Service Attacks
1. Disruption of Communication: A denial of service (DoS) attack could disrupt
the communication between buses and bus stops, leading to system failures and
inaccurate information being displayed. This could reduce the overall reliability of
the system and lead to frustration among commuters.
2. Cybersecurity Measures
: Implementing cybersecurity measures to protect the
system from DoS attacks could increase the overall cost of the system. This could
reduce the overall aordability of the system and limit its adoption.
2.4.10 Economic Constraints
1. High Initial Investment: The installation of solar panels and batteries involves
a high initial investment. This could be a barrier for cities with limited budgets,
particularly in developing countries where funding for public transportation infras-
tructure may be limited.
2. Ongoing Maintenance Costs: Regular maintenance of solar panels, sensors, and
communication modules is necessary to ensure optimal performance. This could
lead to increased operational costs and potential downtime if maintenance is not
performed regularly.
Page 41 of 119
3. Design Improvements
3.1 Implementing Pseudo Stops and Creating a WiFi
Mesh Network
Public transportation systems are continually evolving to provide passengers with real-
time updates and seamless connectivity. One innovative approach to enhancing bus
services is the implementation of pseudo stops, which function as virtual checkpoints
along a bus route. These pseudo stops serve as communication nodes in a localized
WiFi mesh network, allowing for uninterrupted data exchange between bus-mounted
units (BUk) and display units at the stops (DUk).
By using pseudo stops strategically positioned along the route, buses and passengers
receive accurate and real-time updates on arrival times, delays, and capacity. The
network ensures that even in cases where a bus is out of service, the information is
relayed eciently to inform waiting passengers in advance. Additionally, the system
helps to optimize bus services by allowing drivers and operators to assess the number of
people waiting at dierent stops. This capability enables better capacity planning and
improved passenger experience.
Moreover, pseudo stops can act as smart relay points, collecting and forwarding data
across multiple bus routes, ensuring robust communication even in complex urban envi-
ronments. This approach reduces dependency on centralized servers and enhances overall
network resilience. Additionally, by integrating edge computing capabilities, these pseudo
stops can process data locally, reducing latency and improving system response times.
Edge computing further minimizes reliance on cloud infrastructure, thereby enhancing
data privacy and security.
3.2 Utilizing OBD Ports for Enhanced Bus Monitor-
ing
To further improve the system’s eciency, the On-Board Diagnostics (OBD) ports
of buses are utilized. These ports provide vital data about the bus’s operational state
and are connected to an ESP32 microcontroller via Bluetooth. Leveraging OBD
data presents multiple advantages:
• Real-time insights into the bus’s status:
– The system can access crucial parameters such as engine status, fuel con-
Page 42 of 119
sumption, and mileage.
– If the engine is o or experiencing issues, passengers and bus operators can be
informed immediately.
• Predictive analytics for improved service reliability:
– OBD data can be used for tracking the amount of time that a bus takes to
reach the next pseudo stop, improving arrival time predictions.
– Error conditions detected via OBD can provide early warnings of mechanical
issues, allowing proactive maintenance.
• Optimizing Fleet Eciency:
– Real-time OBD diagnostics can assist in planning fuel-ecient routes and
reducing operational costs.
– Monitoring engine health over time allows predictive maintenance, reducing
unexpected breakdowns and improving eet reliability.
By integrating OBD data with the WiFi mesh, the transportation network becomes
smarter and more ecient, ensuring that real-time information is accessible to pas-
sengers and operators alike. Additionally, integrating cloud storage solutions allows his-
torical analysis of vehicle performance and enables long-term service optimization.
3.3 Increasing the Range of ESP32 for Robust Con-
nectivity
The ESP32 microcontroller plays a central role in enabling communication between
buses, pseudo stops, and display units. To optimize its performance, range tests were
conducted using multiple ESP32 boards with connected sensors. Various implementa-
tion methods were explored, including Arduino IDE, Thonny, and Python with
MicroPython or PlatformIO.
Key ndings from these tests include:
• WiFi vs. Bluetooth:
– WiFi was found to be more suitable for long-range communication,
making it ideal for pseudo stops.
– Bluetooth, on the other hand, oers high eciency for short-range data
transfer but poses challenges such as increased power consumption and in-
terference.
• Exploring LoRa (Long Range) Technology:
– LoRa was considered due to its ability to facilitate
long-distance commu-
nication with minimal power consumption.
– However, its lower data rate, high latency, and requirement for additional
hardware made it a secondary option for this project.
Page 43 of 119
– Future implementations could explore hybrid models where LoRa is used for
backbone communication while WiFi handles localized data transmission.
3.4 Establishing Line-of-Sight (Communication Us-
ing Pseudo Stops)
For optimal data transmission, Line-of-Sight (LOS) communication is established
between pseudo stops. LOS (Line of Sight)refers to an unobstructed path for communi-
cation between two points, which minimizes interference and signal degradation.
To ensure LOS:
• Pseudo stops are positioned strategically to provide direct communication
paths.
• The WiFi mesh network is structured in a way that minimizes data loss.
• The bus-mounted unit (BUk) and display units (DUk) can reliably exchange real-
time information about bus arrival times.
• Obstructions such as buildings and trees are accounted for by deploying relay nodes
that can dynamically adapt to environmental changes.
By maintaining clear LOS (Line of Sight)pathways, the system can ensure uninter-
rupted and ecient wireless communication, which is crucial for an eective real-time
public transport information system.
3.5 Tracking Bus Capacity and Informing Waiting
Passengers
To enhance passenger experience, the system incorporates a bus occupancy tracking
feature that monitors and communicates the number of passengers onboard. This is
achieved through:
• Sensor-based capacity monitoring:
– Weight sensors can be used to detect the total load inside the bus, providing
an estimate of the number of passengers.
– Door sensors count the number of people entering and exiting at each stop.
– AI-powered image recognition can further validate passenger counts through
onboard cameras.
• Real-time data relay to bus stops:
– Information about bus occupancy is displayed on the DUk units at bus
stops.
– Passengers can decide whether to wait for a less crowded bus or board the
next available one, improving comfort and reducing overcrowding.
Page 44 of 119
3.6 Conclusion
The implementation of pseudo stops and a WiFi mesh network signicantly en-
hances public transportation eciency. By leveraging ESP32 microcontrollers, OBD
ports, and IR sensors, the system ensures real-time communication between
buses, bus stops, and passengers. Features such as bus occupancy tracking,
LOS (Line of Sight)communication, and capacity planning contribute to a more
reliable and user-friendly service. Additionally, custom protective enclosures ensure
the durability of electronic components, further increasing the system’s robustness.
Overall, this project represents a major step forward in intelligent public trans-
portation by combining cutting-edge communication technologies with practical
implementation strategies.
Page 45 of 119
4. Requirements
4.1 Microcontrollers and Communication Modules
• ESP32 Board: High-performance microcontroller with built-in ESP-NOW sup-
port for low-latency device-to-device communication, optimized for low power con-
sumption and handling simultaneous network connections.
• Dash7 Protocol Module: Ensures robust long-range, low-power wireless com-
munication between bus stops and bus units, providing ecient data exchange even
in urban environments.
• LoRa Protocol Module: Guarantees ultra-long-range transmission with minimal
energy usage, enhancing network scalability.
• BLE Module: Supports short-range, low-power communication for rapid data
transfers between proximate devices, ensuring system responsiveness.
4.2 Sensor Components
• MPU6050: Combines a 3-axis accelerometer and gyroscope for dynamic motion
tracking and orientation sensing.
• Passenger Detection Sensor: Uses passive infrared (PIR (Passive Infrared Sen-
sor)) technology to detect waiting passengers, distinguishing between transient mo-
tion and genuine presence.
• MMA845xQ Digital Accelerometer: Provides precise motion measurements
for bus stop detection and activity logging.
4.3 Display Components
• 7-Segment LCD: Alternates messages in English and Hindi to inform users of
upcoming buses, ensuring clear visibility under various lighting conditions.
• 8x8 Dot Matrix Display: Acts as a supplementary visual indicator for system
messages and graphical icons, ensuring readability in diverse environments.
Page 46 of 119
4.4 LED and Visual Indicators
• RGB LED: Provides dynamic status indication with a range of colors for multiple
system states.
• Bi-Colour LED: Red/green indicator for bus service status.
• Additional LED Indicators:
– Red LED: Signals out-of-service units.
– Red Blinking LED: Alerts critical error conditions.
– Green LED: Conrms normal service operation.
– Green Blinking LED: Indicates waiting passengers at stops.
– White LED: Enhances system aesthetics.
4.5 Power and Energy Management
• Power Bank: Provides uninterrupted operation during primary power failures.
• Solar Panel: Oers renewable energy backup, enhancing resilience during outages.
• Charge Controller: Regulates charging, protecting battery longevity.
• Internal/Backup Battery Modules: Ensure continuous operation during engine-
o scenarios.
• Automatic Power Transition System: Automatically switches between power
sources to maintain functionality.
4.6 Enclosures, Mounting, and Structural Materials
• Bus Unit Box/Bus Stop Unit Box: Rugged, tamper-resistant enclosures pro-
tecting electronics from environmental stresses.
• IP67-Rated Enclosures: Shield electronics from dust and water in harsh condi-
tions.
• Mechanical Fixation Brackets: Secure mounting, preventing theft and stabiliz-
ing units.
• Weatherproof Casings: Protect components from extreme weather.
• Fresnel Lens: Manages light distribution in displays and sensors.
• Verro Board: Provides structural support for mounted panels and devices.
• Burge Strip: Organizes and secures wiring.
Page 47 of 119
4.7 Feedback, Accessibility, and Interface Compo-
nents
• Speech IC: Delivers auditory feedback for visually impaired users.
• PWM (Pulse Width Modulation) Output Module: Generates tactile feed-
back signals, enhancing accessibility.
• Optimized Font Size: Ensures legibility up to 8 feet.
• Flashing Display: Shows real-time data with ±1 minute precision.
4.8 Data Logging and Processing
• Real-Time Clock (RTC (Real-Time Clock)) Module: Provides precise time
synchronization.
• Memory Storage Modules: Archive system data for one week to one month.
• Embedded Software/Firmware: Manages sensor inputs, communications, and
system protocols.
• Bus Activity Logging System:
– Logs bus departure and arrival times.
– Records out-of-service intervals.
– Monitors location and travel data for optimization.
4.9 System Operation Protocols
4.9.1 Bus Operation Protocol
• Multiple buses operate to meet high passenger demand.
• Buses go out-of-service for refuelling, washing, and maintenance.
• Buses stop only when passenger presence is conrmed.
• Detection of waiting passengers for over 30 seconds triggers a blinking LED alert.
4.9.2 Exception Handling Protocol
• Predened code (‘999‘) signals emergencies or unplanned delays.
• Malfunctions must be resolved within 15 minutes.
4.10 Connectivity and Scalability
• Limited GSM/WiFi Use: Reserved for critical updates or initial IP acquisition.
Page 48 of 119
• Wireless Security Protocols: Implement advanced encryption for secure data
transmission.
• Scalability Measures: New stop units integrate quickly, with installation under
1 hour.
4.11 Operational Hours
• Stop Units: Operate from 0700 to 1930 hours, entering power-down mode outside
these hours.
4.12 Stop Unit Detailed Specications
• Display Functionality: Alternates language messages and shows real-time arrival
info.
• Visibility Enhancements: Optimized font sizes and high-contrast backlighting
ensure readability.
• Accessibility Features: Integrates auditory and tactile feedback for universal
accessibility.
• Environmental Resilience: Uses vandal-resistant enclosures for durability.
• Power Backup: Primary battery with optional solar backup ensures continuity.
4.13 Bus-Mounted Unit Detailed Specications
• Component Integration: Includes bi-colour LED for service status and auto-
matic power transition.
• Service Status Indicators: Indicate operational states using red, green, and
white LEDs.
• Operational Coordination: Supports synchronized logging for parallel bus op-
erations.
4.14 Miscellaneous Requirements and Data Collec-
tion
• Data Logging: Records arrival/departure times, service interruptions, and travel
data.
• Connectivity and Updates: GSM/WiFi used minimally to reduce power con-
sumption.
• Installation and Scalability: Adding stops requires only installation and power-
up.
• Survey and Analysis: Monitors operations for optimizing stop durations.
Page 49 of 119
4.15 System Survey and Analysis
• Operational Metrics: Records exact timings for route eciency analysis.
• Solar Panel Deployment: Ensures continuous power at high-trac stops.
• Performance Monitoring: Analyzes data to rene protocols and improve service.
4.16 Requirements Table
S.No. Component
1 12 Volt Batteries
2 12AWG Silicone Wires
3 8X8 Dot matrix Display
4 Burge Strip
5 Bus stop unit Box
6 Bus unit Box
7 Charge Controller
8 ESP 32
9 Fresnel Lens
10 Green Blinking LED
11 Green LED
12 MPU6050
13 Nrf24l01 PA
14 Power Bank
15 Red Blinking LED
16 Red LED
17 RGB LED
18 Solar Panel
19 Verro Board
20 White LED
Page 50 of 119
5. Specications
5.1 Hardware Specications
5.1.1 Core Hardware: ESP32
Description:ESP32 is a low-cost System on Chip (SoC) Microcontroller from Espressif
Systems, the developers of the famous ESP8266 SoC. It is a successor to ESP8266 SoC
and comes in both single-core and dual-core variations of the Tensilica’s 32-bit Xtensa
LX6 Microprocessor with integrated Wi-Fi and Bluetooth.
ESP32 S-Series Specications
• Processor: Dual-core Tensilica Xtensa LX6 (up to 240 MHz)
• Memory: 520 KB SRAM
• Storage: 4 MB Flash memory (expandable)
• Wireless:
– WiFi: 802.11 b/g/n (2.4 GHz)
– Bluetooth: v4.2 BR/EDR and BLE
• GPIO (General Purpose Input/Output): 36 programmable pins
• Peripherals: ADC (Analog-to-Digital Converter), DAC (Digital-to-Analog Con-
verter), I2C (Inter-Integrated Circuit), SPI (Serial Peripheral Interface), UART
(Universal Asynchronous Receiver-Transmitter), PWM (Pulse Width Modulation),
etc.
• Power Consumption:
– Active Mode: 160-260 mA
– Modem-sleep Mode: 20 mA
– Deep-sleep Mode: 10 µA
– Hibernation Mode: 5 µA
ESP32 Usage in NEXTBUS
The ESP32 will take care of real-time location tracking and timing to ensure accurate
updates for passengers. It will also communicate with bus stop displays, keeping them
Page 51 of 119
informed about arrivals and delays, while continuously monitoring service status to en-
sure smooth operations. Additionally, it will log important data for analysis, helping to
improve eciency over time. Power management is another key function, balancing the
bus battery and its internal battery to maintain reliable performance. The ESP32 will
also process switch inputs and control LEDs, enhancing usability and visibility.
For the Display Units (DU), the ESP32 will calculate bus arrival times and manage
display outputs in both English and Hindi to accommodate a diverse passenger base.
To optimize energy consumption, it will incorporate battery-saving measures and follow
a scheduled sleep/wake cycle from 7:00 AM to 7:30 PM. Passenger detection features
will help adjust display behavior based on activity, while solar charging monitoring will
ensure a sustainable and ecient power supply.
5.1.2 Power Supply System
Solar Power System
• Solar Panel: 10W/6A
• Dimensions: 350mm × 280mm × 25mm
• Peak Power: 10W
• Open Circuit Voltage: 21.6V
• Short Circuit Current: 0.61A
• Eciency: 15-18%
• Weather Resistance: IP65 rated
Importance of Solar Power
we need a dependable power source for the bus stop displays, and 10W/6A solar panels are
a great t. These panels can generate enough juice to keep the displays, LED lights, and
sensors working from 7:00 AM to 7:30 PM, even when it’s cloudy. With a current capacity
of 6A, they provide stable power without relying on outside sources, which makes the
system more independent and sustainable. They’re also small, so they’re easy to install
near bus stops and help save money by cutting down on electricity costs. Since many
bus stops are shaded, it’s important to position them properly and use weather-resistant
wiring to make sure they get enough sunlight. Overall, solar power is a low-maintenance
and eco-friendly way to keep everything running smoothly.
5.1.3 Display System
Display Options for DU
• 7-Segment Display:
– 3-digit display (0-999)
– High brightness (outdoor visibility)
– Flashing capability
Page 52 of 119
– Power usage: 20-40 mA per digit
• LCD (Liquid Crystal Display) Option:
– Yellow backlight
– Sizes: 16×2 or 20×4 characters
– I2C (Inter-Integrated Circuit) interface to save GPIO (General Purpose In-
put/Output)
– Power use: 5-15 mA (no backlight), 80-150 mA (with backlight)
LED Indicators
LED: LEDs (Light Emitting Diodes) are widely used for various lighting applications due
to their energy eciency, long lifespan, and compact size.
• DU White LED:
– Bright, downward-pointing
– 30% duty cycle blinking
– Current: 20 mA
• BUk Bi-color LED (Red/Green):
– Dual indication
– Current: 20 mA per color
5.2 Software Specications
We are considering the following possible options:
• Display Management: Options include using a 7-segment display with multi-
plexing control. The software must support alternating messages in English and
Hindi with blinking eects.
• Communication Protocols: Given that GSM and WiFi are not preferred, Blue-
tooth Mesh is being explored as a robust solution for wireless communication be-
tween bus-mounted units (BUk) and display units. Bluetooth Mesh allows multi-
hop communication, improving range and reliability in a distributed system.
• Power Management: The display unit software should ensure ecient battery
utilization, with an automatic shutdown feature after operational hours. Algorithms
for power optimization are under discussion.
Further evaluation and prototyping will help nalize the best combination of these options
to ensure an ecient and reliable system.
Page 53 of 119
5.3 Performance Specications
We will be working towards meeting the following specications in the project. The
software for the P2 NEXTBUS system must meet specic performance criteria to en-
sure reliability, accuracy, and eciency. The key performance specications are outlined
below:
• Response Time: The system must compute and update the estimated arrival
time within 1 second after receiving new data from the bus units.
• Accuracy: The displayed bus arrival time should be accurate to ±1 minute,
considering real-time variations in travel time.
• Communication Latency: Data transmission between the bus-mounted unit
(BUk) and the display unit (DUk) should have a maximum delay of 500 millisec-
onds to ensure real-time updates.
• Power Eciency: The software should optimize power usage to allow the display
units to function for the entire operational window (07:00 - 19:30) on battery power,
with solar power as an optional supplement.
• Data Logging Frequency: Logs related to bus arrival times, stop durations, and
passenger count estimates should be recorded at intervals of 1 minute or upon
signicant status changes.
• System Uptime: The system must maintain an uptime of 99.5% during opera-
tional hours, with minimal downtime for maintenance or updates.
• Scalability: The software should be designed to support future expansions, includ-
ing additional buses and stops, with minimal modications to the core architecture.
These performance specications will guide software development to ensure an ecient
and user-friendly system.
5.4 Man-hour specications
5.4.1 Man-hours
Table 5.1: Man-hours invested
S.no Role Name Entry No Hours
1 Tribe Coordinator and Hard-
ware Design and Fabrication
Saiyam Jain 2022MT11962 9.0
2 Deputy Tribe Coordinator and
Documentation
Shivaani Hari 2022MT11273 9.0
Table continues on the next page
Page 54 of 119
S.no Role Name Entry No Hours
3 Activity Coordinator- Me-
chanical Design and Ideation
Fieldwork
Vagesh Mahajan 2022MT11260 6.0
4 Activity Coordinator-
Software-2
Shrenik Mohan
Sakala
2022MT11920 6.0
5 Activity
Coordinator-
Software-1
Manas Goyal 2022MT11918 6.0
6 Activity Coordinator-Market
Research
Rahul Athipatla 2022MT11277 4.0
7 Activity Coordinator-
Documentation
Nilay Sharma 2022MT12007 10.0
8 Documentation Aahna Jain 2022MT11930 6.0
9 Market Research Abhishek Kumar
Singh
2022MT11276 2.0
10 Mechanical Design and
Ideation Fieldwork
Abhishek Singh 2022MT11934 6.0
11 Mechanical Design and
Ideation Fieldwork
Adarsh Singh 2022MT11285 6.0
12 Software-2 Aditya Goyal 2022EE31761 4.0
13 Market Research Aditya Raj 2022MT61980 2.0
14 Software-1 Ajaypal Kulhari 2022EE11711 4.0
15 Documentation Aman Divya 2022MT11293 3.0
16 Software-1 Ambhore Soham
Bhaskar
2022EE11713 3.0
17 Software-1 Arnav Tiwari 2022MT11267 6.0
18 Software-1 Arpit Mourya 2022EE11728 6.0
19 Market Research Ashmit Nangia 2022EE11989 5.0
20 Market Research Ayush Nayak 2022MT11958 5.0
21 Market Research Ayush Raj 2022MT11944 3.0
22 Software-1 Chintada Srini-
vasarao
2022MT11924 6.0
23 Software-1 Deevyansh Khadria 2022EE31883 3.0
24 Market Research Dev Singh 2022MT11143 2.0
25 Software-2 Devansh Upadhyay 2022MT11931 3.0
Table continues on the next page
Page 55 of 119
S.no Role Name Entry No Hours
26 Software-2 Dhruv Chaurasiya 2022MT11172 0.0
27 Software-2 Galla Yaswant
Venkata Ramana
2022EE11687 6.0
28 Market Research Gauri Agarwal 2021EE10715 6.0
29 Market Research Ishan Bankal 2022EE31779 2.0
30 Documentation Ishant Yadav 2022MT11397 3.0
31 Software-1 Jenit Jain 2022EE11690 6.0
32 Documentation Kabir Uberoi 2022MT61202 8.0
33 Documentation Kaneesha Jain 2022MT11929 7.0
34 Documentation Keshav Rai 2022MT61968 5.0
35 Mechanical Design and
Ideation Fieldwork
Khushi Gupta 2022MT61973 6.0
36 Market Research Krish Singh 2022MT61303 3.0
37 Software-2 Lakshaya Jain 2022MT11933 4.0
38 Documentation Madhav Biyani 2022EE11321 5.0
39 Mechanical Design and
Ideation Fieldwork
Madhav Mahesh-
wari
2022MT61975 6.0
40 Software-1 Mukul Sahu 2022MT11939 6.0
41 Mechanical Design and
Ideation Fieldwork
Nagure Kalyani
Paramanand
2022MT61983 6.0
42 Mechanical Design and
Ideation Fieldwork
Naman Kale 2022MT11960 3.0
43 Software-1 Nimkar Abhinav
Yashwant
2022MT11943 6.0
44 Software-2 Niraj Agarwal 2022MT11921 5.0
45 Software-1 Niranjan Rajeev 2022EE11766 4.0
46 Software-2 Nobin Kidangan
Benny
2022EE11154 6.0
47 Documentation Ojas Sharma 2022EE31746 0.0
48 Documentation Om Goel 2022MT12071 6.0
49 Software Parth Bhardwaj 2022MT11257 2.0
50 Documentation Pratyush Sharma 2022MT61970 4.0
Table continues on the next page
Page 56 of 119
S.no Role Name Entry No Hours
51 Market Research Pratyush Shrivas-
tava
2022EE11660 2.0
52 Software-2 Praveen Lakhara 2022MT11280 3.0
53 Software-1 Priyansh Prakash
Mayank
2022MT11954 6.0
54 Mechanical Design and
Ideation Fieldwork
Priyanshu Jindal 2022EE11668 5.0
55 Software-2 Punit Meena 2022EE11184 5.0
56 Market Research Rahul Rajoria 2022MT11947 2.0
57 Software-2 Raman Jakhar 2022MT11941 5.0
58 Market Research Ranjan Kumar
Singh
2022MT61304 2.0
59 Software-1 Rijul Rudrax Barot 2022EE11664 2.0
60 Software-2 Rudranil Naskar 2022MT11287 3.0
61 Documentation Sachin Hiren
Trivedi
2022EE11190 4.0
62 Mechanical Design and
Ideation Fieldwork
Saksham Kumar
Rohilla
2022EE11709 3.0
63 Documentation Sanya Sachan 2022MT11286 4.0
64 Software-1 Sarthak Gangwal 2022MT11275 6.0
65 Documentation Satvik Prasad S 2022MT11279 4.0
66 Software-1 Shashwat Kasliwal 2022MT11915 5.0
67 Market Research Shivang Goyal 2022MT11269 4.0
68 Software-2 Siddharth Saini 2022MT11283 6.0
69 Documentation Siya Gupta 2022MT11274 5.0
70 Market Research Sparsh Jain 2022MT11917 2.0
71 Mechanical Design and
Ideation Fieldwork
Suhani Soni 2022MT61981 8.0
72 Software-2 Sumit Sonowal 2022MT11296 2.0
73 Software-2 Suneel Masarapu 2022MT11942 3.0
74 Mechanical Design and
Ideation Fieldwork
Sushil Kumar 2022EE31765 5.0
Table continues on the next page
Page 57 of 119
S.no Role Name Entry No Hours
75 Mechanical Design and
Ideation Fieldwork
Syna Rajvanshi 2022MT61974 5.0
76 Documentation Tanya Jain 2022MT11947 5.0
77 Market Research Taru Singhal 2022MT11922 4.0
78 Documentation Tatsam Ranjan
Sharma
2022MT61969 2.0
79 Mechanical Design and
Ideation Fieldwork
Tirth Punit Gol-
wala
2022MT11967 8.0
80 Software-2 Tushar Goyal 2022MT11266 6.0
81 Software-1 Umang Agarwal 2022EE11692 3.0
82 Documentation Utkarsh Dubey 2022MT61045 7.0
83 Software-2 Vatsal Manish Sej-
pal
2022MT11926 4.0
84 Mechanical Design and
Ideation Fieldwork
Viha Singla 2022MT61972 6.0
85 Documentation Yuvraj Singh 202MT11962 2.0
5.4.2 Skillset
Table 5.2: Skillset acquired
S.no Role Name Entry No Skillset
1 Tribe Coordinator and
Hardware Design and
Fabrication
Saiyam Jain 2022MT11962 L
A
T
E
X, soldering
2 Deputy Tribe Coordi-
nator and Documen-
tation
Shivaani Hari 2022MT11273 L
A
T
E
X, Zotero, solder-
ing
3 Activity Coordinator-
Mechanical Design
and Ideation Field-
work
Vagesh Mahajan 2022MT11260 RDWorks
4 Activity Coordinator-
Software-2
Shrenik Mohan
Sakala
2022MT11920 Arduino programming
using TinkerCAD,
SimulIDE
Table continues on the next page
Page 58 of 119
S.no Role Name Entry No Skillset
5 Activity Coordinator-
Software-1
Manas Goyal 2022MT11918 L
A
T
E
X, Arduino pro-
gramming using Tin-
kerCAD, SimulIDE
6 Activity Coordinator-
Market Research
Rahul Athipatla 2022MT11277 Stakeholder Analysis,
Cost Optimisation
7 Activity Coordinator-
Documentation
Nilay Sharma 2022MT12007 L
A
T
E
X, Zotero
8 Documentation Aahna Jain 2022MT11930 Cost analysis from dif-
ferent websites
9 Market Research Abhishek Kumar
Singh
2022MT11276 FreeCADweb and
L
A
T
E
X
10 Mechanical Design
and Ideation Field-
work
Abhishek Singh 2022MT11934 RDWorks, Laser Cut-
ting
11 Mechanical Design
and Ideation Field-
work
Adarsh Singh 2022MT11285 RDWorks, Laser Cut-
ting
12 Software-2 Aditya Goyal 2022EE31761 FreeCADweb
13 Market Research Aditya Raj 2022MT61980 Circuit building
14 Software-1 Ajaypal Kulhari 2022EE11711 Circuit Design
15 Documentation Aman Divya 2022MT11293 FreeCADweb
16 Software-1 Ambhore Soham
Bhaskar
2022EE11713 Arduino functions like
Analogwrite().RC Fil-
ters
17 Software-1 Arnav Tiwari 2022MT11267 TinkerCAD,SimulIDE
18 Software-1 Arpit Mourya 2022EE11728 PCB software LTM
19 Market Research Ashmit Nangia 2022EE11989 Market Analysis
20 Market Research Ayush Nayak 2022MT11958 Stakeholder Analysis,
Cost Optimisation
21 Market Research Ayush Raj 2022MT11944 Market base analysis
22 Software-1 Chintada Srini-
vasarao
2022MT11924 Circuit Simulation
in TinkerCAD and
SimulIDE
23 Software-1 Deevyansh Khadria 2022EE31883 Circuit Simulation in
SimulIDE
24 Market Research Dev Singh 2022MT11143 Circuit Analysis
Table continues on the next page
Page 59 of 119
S.no Role Name Entry No Skillset
25 Software-2 Devansh Upadhyay 2022MT11931 Circuit Design
26 Software-2 Dhruv Chaurasiya 2022MT11172 Circuit Simulations in
TinkerCAD
27 Software-2 Galla Yaswant
Venkata Ramana
2022EE11687 Basics of TinkerCAD
28 Market Research Gauri Agarwal 2021EE10715 Stakeholder Analysis
29 Market Research Ishan Bankal 2022EE31779 Circuit Analysis,
GitHub
30 Documentation Ishant Yadav 2022MT11397 L
A
T
E
X
31 Software-1 Jenit Jain 2022EE11690 Circuit simulation in
LTspice
32 Documentation Kabir Uberoi 2022MT61202 L
A
T
E
X, PlantText
33 Documentation Kaneesha Jain 2022MT11929 Cost analysis and op-
timization, L
A
T
E
X
34 Documentation Keshav Rai 2022MT61968 L
A
T
E
X
35 Mechanical Design
and Ideation Field-
work
Khushi Gupta 2022MT61973 RDWorks, Laser Cut-
ting
36 Market Research Krish Singh 2022MT61303 Circuit Analysis
37 Software-2 Lakshaya Jain 2022MT11933 Circuit Simulations in
TinkerCAD
38 Documentation Madhav Biyani 2022EE11321 L
A
T
E
X
39 Mechanical Design
and Ideation Field-
work
Madhav Mahesh-
wari
2022MT61975 FreeCADweb
40 Software-1 Mukul Sahu 2022MT11939 Circuit Simulations in
TinkerCAD, Wokwi,
Basic Display Pro-
gramming
41 Mechanical Design
and Ideation Field-
work
Nagure Kalyani
Paramanand
2022MT61983 RDWorks, Laser Cut-
ting
42 Mechanical Design
and Ideation Field-
work
Naman Kale 2022MT11960 FreeCADweb
Table continues on the next page
Page 60 of 119
S.no Role Name Entry No Skillset
43 Software-1 Nimkar Abhinav
Yashwant
2022MT11943 TinkerCAD,WOKWI
circuit simulations for
display programming
using LiquidCrystal
I2C
44 Software-2 Niraj Agarwal 2022MT11921 TinkerCAD
45 Software-1 Niranjan Rajeev 2022EE11766 TinkerCAD
46 Software-2 Nobin Kidangan
Benny
2022EE11154 TinkerCAD, Wokwi
47 Documentation Ojas Sharma 2022EE31746 L
A
T
E
X
48 Documentation Om Goel 2022MT12071 L
A
T
E
X, PlantText
49 Software Parth Bhardwaj 2022MT11257 L
A
T
E
X
50 Documentation Pratyush Sharma 2022MT61970 L
A
T
E
X
51 Market Research Pratyush Shrivas-
tava
2022EE11660 Cost Optimization,
L
A
T
E
X
52 Software-2 Praveen Lakhara 2022MT11280 Circuit Simulations in
TinkerCAD
53 Software-1 Priyansh Prakash
Mayank
2022MT11954 Circuit simulation in
WOKWI and Tinker-
CAD for LiquidCrys-
tal I2C display pro-
gramming
54 Mechanical Design
and Ideation Field-
work
Priyanshu Jindal 2022EE11668 Altium, LtSpice Simu-
lations
55 Software-2 Punit Meena 2022EE11184 TinkerCAD, Wokwi
56 Market Research Rahul Rajoria 2022MT11947 TinkerCAD
57 Software-2 Raman Jakhar 2022MT11941 TinkerCAD
58 Market Research Ranjan Kumar
Singh
2022MT61304 using tools and tech-
niques to nd and x
problems in hardware
and software.
59 Software-1 Rijul Rudrax Barot 2022EE11664 TinkerCAD
60 Software-2 Rudranil Naskar 2022MT11287 FreeCADweb, L
A
T
E
X
61 Documentation Sachin Hiren
Trivedi
2022EE11190 L
A
T
E
X
Table continues on the next page
Page 61 of 119
S.no Role Name Entry No Skillset
62 Mechanical Design
and Ideation Field-
work
Saksham Kumar
Rohilla
2022EE11709 Circuit Design
63 Documentation Sanya Sachan 2022MT11286 Cost Analysis, L
A
T
E
X
64 Software-1 Sarthak Gangwal 2022MT11275 Circuit Simulations in
TinkerCAD, Wokwi,
Basic Display Pro-
gramming
65 Documentation Satvik Prasad S 2022MT11279 Analyzing com-
ponents and It’s
evaluating market
value .
66 Software-1 Shashwat Kasliwal 2022MT11915 L
A
T
E
X
67 Market Research Shivang Goyal 2022MT11269 L
A
T
E
X
68 Software-2 Siddharth Saini 2022MT11283 TinkerCAD
69 Documentation Siya Gupta 2022MT11274 Cost analysis
70 Software-1 Sparsh Jain 2022MT11917 FreeCADweb
71 Mechanical Design
and Ideation Field-
work
Suhani Soni 2022MT61981 RDWorks, Laser
Cutting, ESP32 con-
troller range testing,
Arduino, SWOT
Analysis
72 Software-2 Sumit Sonowal 2022MT11296 Circuit Simulations in
TinkerCAD
73 Software-2 Suneel Masarapu 2022MT11942 Circuit Simulations in
SimulIDE
74 Mechanical Design
and Ideation Field-
work
Sushil Kumar 2022EE31765 Circuit Design
75 Mechanical Design
and Ideation Field-
work
Syna Rajvanshi 2022MT61974 RDWorks, Laser Cut-
ting
76 Documentation Tanya Jain 2022MT11947 Optimal cost estima-
tion techniques, re-
search
77 Market Research Taru Singhal 2022MT11922 L
A
T
E
Xand FreeCAD-
web
Table continues on the next page
Page 62 of 119
S.no Role Name Entry No Skillset
78 Documentation Tatsam Ranjan
Sharma
2022MT61969 3-D Modelling
79 Mechanical Design
and Ideation Field-
work
Tirth Punit Gol-
wala
2022MT11967 RDWorks, Laser Cut-
ting
80 Software-2 Tushar Goyal 2022MT11266 TinkerCAD
81 Software-1 Umang Agarwal 2022EE11692 Circuit analysis
82 Documentation Utkarsh Dubey 2022MT61045 L
A
T
E
X, Project Libre
83 Software-2 Vatsal Manish Sej-
pal
2022MT11926 RDWorks
84 Mechanical Design
and Ideation Field-
work
Viha Singla 2022MT61972 RDWorks, Laser Cut-
ting
85 Documentation Yuvraj Singh 2022EE11715 L
A
T
E
X
5.4.3 How Assignment was Done
We divided the assignments among the team members based on their individual strengths
and preferences. This was achieved by documenting each member’s skillset and areas of
interest. We strategically assigned tasks, such as delegating the majority of hardware and
debugging responsibilities to Electrical Engineering students, and assigning documenta-
tion and software development to Mathematics students respectively. This approach fos-
tered a highly coordinated and ecient team where each member eectively contributed
to the project’s timely completion.
5.4.4 Surplus Manpower
To date, the project has progressed smoothly without encountering any instances of sur-
plus manpower. Proactive resource allocation and regular progress reviews have ensured
that team members are eectively utilized and their skills are aligned with the project’s
evolving needs. This proactive approach minimizes the risk of under utilization and allows
for ecient and timely task completion.
Page 63 of 119
6. Design
6.1 Bus Unit
The bus unit will be made via 3-D printing, a prototype of which is given below (Fig.
6.1). It is an embedded system designed to facilitate communication between the bus
and the bus stop. This ensures that passengers receive real-time updates on bus status
and expected arrival times. Two possible systems are being evaluated for this purpose:
Figure 6.1: A prototype of the bus unit
6.1.1 Bluetooth Module with ELM327 Interface
The ELM327 interface is connected to the separator (See Fig. 6.2). It collects essen-
tial operational parameters such as speed, distance covered, brake functioning, and de-
acceleration time. The data collected by the ELM327 module is transmitted wirelessly
using Bluetooth technology to an onboard ESP32 module mounted to a PCB. This en-
sures robust and low-latency communication within the bus. The ESP32 module onboard
leverages AT Commands (Attention Commands) to communicate with the ELM. Once
processed, the information is forwarded to an ESP32 module installed at the bus stop.
The ESP then interprets this data to dynamically display wait times and other relevant
information to waiting passengers.
Page 64 of 119
Figure 6.2: Separator Port of OBD2
6.1.2 Motion Processing Unit (MPU6050)
The dierence in this approach arises in the initial stages of the data collection methodol-
ogy. The MPU sensor is integrated to independently capture motion-related data without
the need for a physical connection. The MPU module transmits its data directly to the
ESP32 through the connections shown in Fig. 6.3.
Figure 6.3: MPU6050 connected with ESP32
Page 65 of 119
6.2 Bus Stop Unit
We will be including the following components in the bus stop unit:
6.2.1 Component Functions
• Dot Matrix Display: The dot matrix display is used to show real-time bus arrival
times and status messages. It provides high visibility and supports multi-language
text display.
• Fresnel Lens: A Fresnel lens is placed over the dot matrix display to enhance
visibility, especially in outdoor conditions. It improves readability by focusing and
magnifying the emitted light.
• PCB (Printed Circuit Board): The PCB serves as the backbone of the bus
stop module, connecting all electronic components, including the microcontroller,
power circuits, and display drivers.
• Veroboard: The veroboard is used for prototyping and testing circuits before nal-
izing the PCB design. It allows quick modications and ensures proper connectivity
between components.
• ESP32 Microcontroller: The ESP32 is the core processing unit of the bus stop
module. It handles communication with the bus-mounted units (BUk), processes
incoming data, and controls the display output.
6.2.2 Integration and Working Mechanism
The bus stop module operates as follows:
1. The ESP32 receives real-time bus location data from the bus-mounted unit via
Bluetooth Mesh.
2. The ESP32 processes this data and calculates estimated arrival times.
3. The dot matrix display then updates with the latest arrival time and bus status.
4. The Fresnel lens enhances the display visibility for passengers, ensuring clear
readability in varying lighting conditions.
5. The PCB connects the power supply, display drivers, and communication modules,
enabling seamless operation.
6. The veroboard is used in the development phase to test connections and validate
circuit designs before transferring them to a PCB.
6.3 Display Unit
6.3.1 MAX7219 and Dot Matrix
• The MAX7219, an 8-digit serially interfaced LED driver, will be used in this pro-
totype. A Fresnel lens will be employed to enhance visibility for viewers.
Page 66 of 119
• The MAX7219/MAX7221 are compact serial input/output common-cathode dis-
play drivers designed to interface with microprocessors (µP s). They support 7-
segment numeric LED displays of up to 8 digits, bar-graph displays, or 64 individ-
ual LEDs. These ICs integrate a BCD code-B decoder, multiplex scan circuitry,
segment and digit drivers, and an 8×8 static RAM for storing digit data. Only a
single external resistor is required to regulate the segment current for all LEDs.
• The module utilizes a 4-wire serial interface, making it compatible with common
µP s. Individual digits can be addressed and updated independently without rewrit-
ing the entire display.
• The MAX7219/MAX7221 allow users to select between code-B decoding and no-
decoding for each digit. Additionally, the devices feature a low-power 150µA shut-
down mode, analog and digital brightness control, a scan-limit register that enables
the display of 1 to 8 digits, and a test mode that illuminates all LEDs simultane-
ously.
6.3.2 Data and Control
NRF Module
• We will be using the NRF module for wireless communication in our project. This
module operates at 2.4 GHz and provides a reliable and low-power transmission sys-
tem. The NRF module allows seamless data transmission between devices, making
it suitable for IoT applications and embedded systems.
• Its low power consumption and high data rate capabilities make it an good choice
for our communication needs.
6.4 Position Tracking Comparatives
For position tracking, we have four potential options, each with its own advantages and
limitations.
6.4.1 GPS using the Neo 6M Module
The Neo 6M GPS module provides positioning data without requiring any additional
hardware beyond the module itself. According to online specications, the module oers
an accuracy of approximately 2-3 meters under ideal conditions. However, real-world ac-
curacy can vary due to several factors, including satellite connectivity, weather conditions
and obstructions.
Under optimal conditions, accuracy can reach as high as 2 meters. However, in environ-
ments with signicant interference, accuracy may deteriorate to as low as 20 meters. In
addition to providing position data, the GPS module can also deliver velocity information.
The cost of a Neo 6M GPS module typically falls within the range of 200 to 800,
making it an aordable solution. However, its dependency on satellite visibility could be
a drawback.
Page 67 of 119
6.4.2 Bus’s On-Board Diagnostics (OBD)
Most modern cars and buses come equipped with an On-Board Diagnostics (OBD)
system, but it is yet to be veried whether the shuttle buses support this feature. OBD
systems provide velocity data, which is the same as what is displayed on the dashboard
speedometer.
To determine the distance covered, sampling and integration of velocity data are
required. However, this method introduces a signicant risk of error accumulation over
time. Small inaccuracies in velocity readings or sampling intervals can lead to progres-
sively larger discrepancies in calculated distance.
Using the OBD system requires an OBD2 scanner, which is available in a price range of
200 to 800, depending on the features oered. Additionally, the extracted data must
be transmitted to an Arduino or ESP32 microcontroller for further processing. While
this is theoretically possible, the exact implementation method, including communication
protocols between the OBD2 scanner and Arduino, requires further exploration through
Arduino forums and technical documentation.
There are multiple OBD scanner types and communication protocols (such as CAN,
K-Line, and Bluetooth/Wi-Fi transmission) that need to be investigated to ensure
compatibility and feasibility for our application.
6.4.3 MPU6050 Accelerometer/Gyroscope
The MPU6050, included in our starter kit, is a sensor module containing both an
accelerometer and a gyroscope. Using accelerometer data, we can estimate the distance
traveled by performing double integration of the acceleration values. However, this
approach is highly prone to error accumulation, making it less reliable than the other two
options.
Some technical sources indicate that the MPU6050, being a low-cost component, tends
to have a relatively high error margin. The cheapest (at 100 mg) loses its ability to
give 50-meter accuracy after around 10 seconds, while the best accelerometer (at 10 �g)
loses its 50-meter accuracy after around 17 minutes. However, these concerns are often
associated with scenarios where motion occurs in multiple directions. In our case, where
bus movement is primarily linear on relatively at roads, the acceleration in the
z-direction remains constant, potentially reducing some sources of error.
Instead of relying on the accelerometer alone, another possible approach is to use the
gyroscope on the bus wheels to calculate distance traveled. However, the feasibility
and accuracy of this method are uncertain, and further testing would be required to
determine whether it provides meaningful improvements.
6.4.4 RSSI‐Based Node Localization and Bus Tracking
To augment GPS, OBD and inertial methods, we use RSSI readings from roadside nodes
to infer bus position without satellites. The bus’s master node polls all nearby nodes
(e.g. 1 Hz) and selects the one with the highest RSSI (dBm) as the closest. During setup,
we record RSSI at known distances and t a log‐distance path‐loss model
RSSI(d) = RSSI
0
− 10 n log
10
(
d
d
0
)
.
Page 68 of 119
In operation, this yields a continuous estimate
ˆ
d = d
0
× 10
(RSSI
0
−RSSI
meas
)/(10 n)
.
Environmental Considerations
• Weather (rain, fog, humidity) and LOS obstructions (buildings, foliage, vehi-
cles) cause RSSI uctuations.
• Multipath & Interference can add 5–10 dB noise; smoothing lters (e.g. mov-
ing‐average) help.
RSSI‐based localization delivers real‐time, low‐cost (�200–400 per node) proximity detec-
tion even where GPS is unreliable, but its 5–20 m distance estimates are noisy and easily
skewed by weather, obstructions and interference—so it demands careful calibration, l-
tering and fusion with OBD or occasional GPS xes.
6.4.5 Comparison Table
Method Accuracy Cost () Key Limitations
GPS (Neo 6M) 2-20 meters 200-600 Aected by obstructions,
weather, satellite visibility
OBD (Bus Sys-
tem)
Speedometer ac-
curacy
200-800 Requires integration; cumu-
lative error in distance cal-
culation
MPU6050
(Accelerome-
ter/Gyro)
High error over
time
Included in kit Error accumulation from
double integration
RSSI‑Based
Node Localiza-
tion
5–20 meters 200-400 Susceptible to weather
(rain, fog, humidity)
and LOS obstructions;
multipath/reections;
requires calibration of
RSSI→distance mapping
Table 6.1: Comparison of Position Tracking Methods
6.4.6 Comparing Accuracy and Feasibility
From an accuracy standpoint, GPS and OBD are expected to outperform the accelerometer-
based approach. The MPU6050’s error accumulation makes it less suitable for long-
term distance tracking, especially over extended routes, and RSSI is inconsistent with
respect to changes in weather conditions and is also aected by LOS obstructions.
Between GPS and OBD, the choice remains uncertain. Each has its own advantages
and drawbacks:
Page 69 of 119
• GPS is self-contained, requires no integration with the vehicle’s internal systems,
and provides both position and velocity data. However, it is highly dependent
on environmental factors and can suer from reduced accuracy in obstructed
areas.
• OBD provides direct velocity readings from the vehicle’s onboard system,
ensuring accuracy comparable to the dashboard speedometer. OBD is better both
for motion detection and for more accurate distance prediction. However, it re-
quires sampling and integration, which introduces the possibility of cumulative
error. Additionally, compatibility with the shuttle buses is yet to be veried, and
integration with Arduino or ESP32 requires further exploration.
6.4.7 Conclusion
At this stage, both GPS and OBD appear to be viable options, but further testing
and research are needed to determine the best choice. Key next steps include:
• Testing GPS performance in real-world shuttle conditions to evaluate its
accuracy in our specic environment.
• Conrming OBD compatibility with the shuttle buses and investigating
communication protocols for integration with Arduino/ESP32.
• Exploring hybrid solutions, such as using OBD for velocity tracking while lever-
aging GPS for position validation, to minimize error accumulation.
Each method has its trade-os, and selecting the most suitable approach will depend
on the balance between accuracy, ease of implementation, and robustness in real-world
conditions.
6.5 WiFi Mesh vs. BLE Mesh Comparatives
6.5.1 Comparison of WiFi Mesh and BLE Mesh
1. Data Throughput & GPS Updates: BLE mesh has lower data rates, making
it unsuitable for real-time applications like live GPS tracking. WiFi mesh, on the
other hand, can handle GPS updates seamlessly.
2. Range & Node Density: BLE mesh has a shorter range compared to WiFi mesh.
This means a BLE-based system would require a higher density of ESP32 nodes,
increasing both hardware costs and complexity.
3. Impact on Campus WiFi: The additional load from a WiFi mesh network for
buses would be minimal compared to existing WiFi usage on campus, making it a
feasible solution.
4. Throughput Considerations: While BLE mesh has lower bandwidth, it can still
handle small-scale data transmission. However, for live GPS tracking, WiFi mesh
is the superior choice due to its higher data rates.
5. Node Density & Connectivity: BLE mesh benets from a higher density of
nodes as it improves network connectivity by creating more transmission routes.
Page 70 of 119
However, increased relays may introduce latency. Given the limited number of
nodes in our system, WiFi mesh is a better option for faster and more ecient
communication.
6. Power Consumption: BLE mesh is more power-ecient than WiFi mesh. How-
ever, since our system will use power banks (included in the starter kit), the power-
saving benets of BLE mesh are negligible.
7. Latency & Precision: BLE mesh relies on relayed transmissions, which can
introduce delays. Since precise bus arrival times are crucial, WiFi mesh—with its
lower latency—is the better choice.
8. Coverage: WiFi mesh has a greater physical coverage range than BLE mesh. BLE
mesh extends coverage through message relaying, which can introduce ineciencies
in larger deployments.
9. ESP32 Compatibility: Both WiFi and BLE mesh are compatible with ESP32,
so hardware compatibility is not a limiting factor in the decision.
6.5.2 Hybrid Approach: The Best of Both Worlds
• BLE Mesh for Low-Power Sensors: Deploy BLE mesh at bus stops where
power consumption is a concern. These sensors don’t require high bandwidth and
can eciently transmit low-data signals like bus arrival triggers.
• WiFi Mesh on Buses: Use WiFi mesh for real-time GPS updates and other data
transmissions, ensuring minimal latency and higher accuracy for tracking.
6.5.3 Conclusion
By leveraging a hybrid approach—using BLE mesh for stationary low-power sensors
and WiFi mesh for real-time bus tracking—we can achieve a balance of eciency, cost-
eectiveness, and performance.
6.6 Latency, Power, Connectivity, Cost, and Integra-
tion Comparatives
6.6.1 Latency Performance
LoRa P2P:
• Data Rate: Very low (a few hundred bps to tens of kbps), leading to longer
transmission times.
• Latency: Lower throughput and longer packet processing introduce delays, making
it unsuitable for near-instantaneous updates.
NRF P2P:
• Data Rate: High (up to 2 Mbps), enabling near-real-time communication.
• Latency: Minimal, ensuring almost instantaneous updates for bus stop displays.
Page 71 of 119
Why NRF Wins: For NEXTBUS, where low latency is crucial, NRF P2P’s high-speed
transmission and minimal delay far outperform LoRa P2P.
6.6.2 Power Eciency
LoRa P2P:
• Consumption: Optimized for low power, ideal for battery-powered remote appli-
cations.
• Operation: Designed for intermittent transmissions, conserving energy by sending
small packets at spaced intervals.
NRF P2P:
• Consumption: Also low-power but can have slightly higher energy usage due to
continuous communication.
• Contextual Advantage: In NEXTBUS, solar-charged power banks negate the
impact of minor energy consumption dierences.
Why NRF Wins: Given the availability of solar power, the slightly higher energy draw
of NRF P2P is an acceptable trade-o for its superior performance.
6.6.3 Connectivity and Environmental Robustness
LoRa P2P:
• Range: Operates in sub-GHz bands, covering several kilometers.
• Robustness: Strong penetration through obstacles and weather resistance, suit-
able for rural deployments.
NRF P2P:
• Range: Limited to 100–150 meters in the 2.4 GHz band.
• Mitigation via Relays: Additional nodes can bridge gaps in a campus environ-
ment.
• Interference Considerations: Frequency hopping and channel selection mitigate
WiFi and device interference.
Why NRF Wins: The campus-scale deployment with relayers eectively addresses
range limitations, ensuring robust, high-speed connectivity.
6.6.4 Cost Considerations
LoRa P2P:
• Unit Cost: Moderately priced modules with cost savings due to reduced relay
node requirements.
• Deployment: Reducing extra relay nodes can be an advantage in cost-sensitive
scenarios.
Page 72 of 119
NRF P2P:
• Unit Cost: Cost-eective per module.
• Additional Nodes: Extra relays are needed for coverage but remain a marginal
cost in this context.
Why NRF Wins: The added cost of relayers is justied by NRF’s superior latency
performance and is manageable within the available budget.
6.6.5 Integration and Feature Set
LoRa P2P:
• Conguration: Supports adjustable spreading factors and strong error correction.
• Complexity: Requires ne-tuning for latency-sensitive applications.
NRF P2P:
• Ease of Use: Extensive documentation and libraries simplify integration.
• Advanced Features: Multiple data pipes, customizable protocols, and frequency
hopping improve performance.
Why NRF Wins: Its ease of integration and advanced features optimize performance
for the NEXTBUS system.
6.6.6 Conclusion
While LoRa P2P excels in range and power eciency, the critical requirements of the
NEXTBUS project—low latency, high-speed communication, and eective use of relayers—
make NRF P2P the superior choice. With solar power eliminating energy concerns and
the budget accommodating additional nodes, NRF P2P not only meets but exceeds
NEXTBUS performance needs. Its rapid transmission, strong integration capabilities,
and real-time capabilities rmly justify its selection for the system.
6.7 Sensor Comparison
A Gate Sensor detects the opening and closing of the bus door and can count the number
of passengers boarding or alighting.
6.7.1 Types of Gate Sensors
• Infrared (IR) Sensors: Detect passengers based on light interruption.
• Ultrasonic Sensors: Use sound waves to detect movement.
• RFID-Based Sensors: Detect passengers using RFID tags (smart cards).
• Computer Vision (AI-based): Uses a camera and AI to count passengers.
Page 73 of 119
6.7.2 Cost Analysis
• Low-cost options: IR and ultrasonic sensors (INR 1,000–5,000 per unit).
• Medium-cost options: RFID-based (INR 5,000–15,000 per unit).
• High-cost options: AI-based vision (INR 50,000+ for hardware and software).
6.7.3 Advantages
• Tracks real-time passenger count.
• Helps optimize bus occupancy.
• Enhances security and revenue tracking.
• Works well with contactless ticketing.
6.7.4 Disadvantages
• Accuracy issues (IR/ultrasonic may miscount overlapping passengers).
• AI-based systems require maintenance and high computing power.
• RFID requires all passengers to have valid RFID cards.
A Weight Sensor is installed on the vehicle oor or suspension system to measure the
total load (passengers + cargo).
6.7.5 Types of Weight Sensors
• Load Cell Sensors: Measure force applied on the bus oor.
• Axle-based Sensors: Measure pressure on the bus suspension system.
6.7.6 Cost Analysis
• Low-cost options: Basic load cells ( INR 5,000–15,000 per unit).
• High-cost options: Advanced axle-based sensors ( INR 50,000+ for a full system).
6.7.7 Advantages
• Provides real-time passenger weight data.
• Prevents overloading and enhances safety.
• Reduces fuel wastage and optimizes route planning.
6.7.8 Disadvantages
• Cannot dierentiate between passengers and heavy baggage.
• Expensive for precise measurement.
• Requires calibration for accuracy.
Page 74 of 119
6.7.9 Final Comparison: Gate Sensor vs. Weight Sensor
Factor Gate Sensor Weight Sensor
Cost Cheaper (INR 1,000–50,000) More expensive (INR 5,000–1,00,000)
Accuracy Moderate (depends on sensor type) High for total weight but cannot count individuals
Passenger Counting Yes (individual tracking possible) No (only measures total weight)
Overloading Detection No Yes
Integration with Ticketing Yes No
Maintenance Low to moderate High
Best Use Case Public transportation for analytics and ticketing Freight and overloading control
Table 6.2: Comparison between Gate Sensor and Weight Sensor
6.7.10 Conclusion
Considering the circumstances of IIT’s, people do not mind standing while travelling so
our only goal then is to avoid overloading. Even if we assume people standing is an
issue, we can estimate the weight of a fully occupied bus and provide estimates from the
same. Thus, it is preferable to use weight sensors over gate sensors even if they are costly
because gate sensors are very unreliable, considering that people usually board the bus
in a very chaotic manner, which may lead to substantial errors.
6.8 Network Design
The communication architecture involves every stop communicating with every other stop
and every bus in the network. It uses a ESP32 module on each bus and each stop. The
communication between modules is via NRF signals. Nearby bus from stop is detected
by the RSSI strength of NRF signals. It will take the signal from the ESP device on
the bus to capture the bus arrival and then send it to the next bus stop. This ensures
the system’s scalability and ensures a peer-to-peer communication network is established.
This helps in system robustness.
Bus1 Bus2
Stop1 Stop2
Figure 6.4: Network Graph for 2 Buses and 2 Stops
Page 75 of 119
6.9 Control Flow Diagram
Control Flow The control ow of our system is shown in Figure 6.5. The vehicle’s onboard
diagnostics (OBD II) port is accessed through an OBD Separator, which allows multiple
simultaneous reads. The ELM 327 module is connected to this port to extract key vehicle
parameters such as speed and engine status.
Polling occurs every 2000 milliseconds to capture real-time vehicle data, which is pro-
cessed by an ESP module installed on the bus. This module transmits the data to an
ESP32 unit at the bus stop. The received data is then processed and displayed on a dot
matrix, providing estimated arrival times to passengers waiting at the stop.
The wired and wireless communication paths between dierent components are depicted
in the owchart. Solid arrows represent signal transmission, while physical connections
are indicated by direct links.
OBD Separator (Splits OBD II)
ELM 327 Reads Vehicle Data
Polling Data Every 2000ms
ESP (On Bus) Processes Data
ESP32 (At Bus Stop) Receives Data
Dot Matrix Displays Arrival Time
Figure 6.5: Flowchart of the OBD Data Processing System
6.10 Arduino Code
6.10.1 MPU6050 Sensor Integration
1 # in clu de <Wire.h>
2 # in clu de <Adafruit_MPU6050 .h>
3 # in clu de <Adafruit_Sensor.h>
4
5 Adafruit_MPU6050 mpu;
6
7 void setup () {
8 Serial .begin (115200) ;
9 while (! Serial);
10
11 Serial .println("Initializing MPU6050 ...");
12
13 // Start I2C communication
Page 76 of 119
14 if (! mpu. begin ()) {
15 Serial .println("MPU6050 not found! Check connections .");
16 while (1);
17 }
18
19 Serial .println("MPU6050 Found!");
20
21 // Configure settings
22 mpu.setAccelerometerRange(MPU6050_RANGE_2_G);
23 mpu.setGyroRange( MPU6050_RANGE_250_DEG);
24 mpu.setFilterBandwidth (MPU6050_BAND_21_HZ );
25
26 delay (100);
27 }
28
29 void loop() {
30 sensors_event_t accel , gyro , temp;
31 mpu.getEvent (& accel , &gyro , &temp);
32
33 // Print Accelerometer values
34 Serial .print("Accel X: "); Serial.print( accel .acceleration.x);
Serial .print(" m/s² ");
35 Serial .print("Y: "); Serial.print(accel.acceleration .y);
Serial .print(" m/s² ");
36 Serial .print("Z: "); Serial.print(accel.acceleration .z);
Serial .println(" m/s² ");
37
38 // Print Gyroscope values
39 Serial .print("Gyro X: "); Serial.print(gyro .gyro.x);
Serial .print(" rad/s ");
40 Serial .print("Y: "); Serial.print(gyro.gyro.y); Serial.print ("
rad/s ");
41 Serial .print("Z: "); Serial.print(gyro.gyro.z);
Serial .println(" rad/s ");
42
43 // Print Temperature
44 Serial .print("Temperature: "); Serial.print( temp.temperature);
Serial .println(" °C");
45
46 Serial .println ();
47 delay (500);
48 }
Listing 6.1: Arduino code to initialize and read from MPU6050 sensor
Page 77 of 119
Figure 6.6: Your caption here
6.10.2 Dot Matrix Scrolling Display
1 # in clu de <MD_Parola.h>
2 # in clu de <MD_MAX72xx.h>
3 # in clu de <SPI.h>
4
5 // Define hardware type , number of devices , and CS pin
6 # define HARDWARE_TYPE MD_MAX72XX :: FC16_HW
7 # define MAX_DEVICES 1 // Number of 8x8 matrices
8 # define CS_PIN 5 // Chip Select pin for ESP32
9
10 // Initialize the Parola library
11 MD_Parola display = MD_Parola (HARDWARE_TYPE , CS_PIN , MAX_DEVICES);
12
13 void setup () {
14 // Initialize the display
15 display.begin ();
16
17 // Set intensity ( brightness ) of the display (0-15)
Page 78 of 119
18 display. setIntensity (5);
19
20 // Clear any previous text or animations on the display
21 display. displayClear ();
22
23 // Set the scrolling speed (lower value = faster scroll)
24 display.setSpeed (50);
25
26 // Set text alignment (centered , left , right , etc.)
27 display. setTextAlignment( PA_CENTER );
28
29 // Set the text to be displayed
30 display.print ("Hello !");
31 }
32
33 void loop() {
34 // Animate the text (scrolling or static)
35 if ( display .displayAnimate ()) {
36 // Loop the message or set a new message here if needed
37 display. displayReset ();
38 }
39 }
Listing 6.2: Arduino code to scroll text on an 8x8 Dot Matrix using MD_Parola
Figure 6.7: Simulating Dot matrix display
6.10.3 OBD2 ELM327 Connecting Code
1 # in clu de "BluetoothSerial.h"
2 # in clu de "ELMduino .h"
3
4 # define ELM_PORT SerialBT
5 # define ESP_BLUETOOTH_NAME "ESP32"
6 # define ELM_BLUETOOTH_NAME "placeholder"
7
8 BluetoothSerial SerialBT;
Page 79 of 119
9 ELM327 myELM327 ;
10
11 void setup ()
12 {
13 // Initialising connection
14 delay (100);
15 Serial.begin (115200);
16 ELM_PORT .begin(ESP_BLUETOOTH_NAME , true );
17
18 Serial.println("Attempting to connect to ELM327 ...");
19
20 if (! ELM_PORT .connect( ELM_BLUETOOTH_NAME))
21 {
22 Serial .println("Couldn't connect to OBD scanner - Phase 1");
23 delay (3000);
24 while (1);
25 }
26
27 if (! myELM327 .begin(ELM_PORT))
28 {
29 Serial .println("Couldn't connect to OBD scanner - Phase 2");
30 delay (3000);
31 while (1);
32 }
33
34 Serial.println("Connected to ELM327");
35 }
36
37 void loop()
38 {
39 float mph = -1;
40 mph = myELM327.mph ();
41 if ( myELM327. status == ELM_SUCCESS )
42 {
43 Serial .print("MPH: "); Serial. println (mph);
44 }
45 else
46 printError();
47
48 if (! myELM327 .connected)
49 {
50 Serial .println("Lost connection..");
51 ELM_PORT.connect (ELM_BLUETOOTH_NAME );
52 Serial .println("reconnecting ..");
53 delay (500);
54 myELM327.begin (ELM_PORT );
55 }
56
57 delay (500);
58 }
59
Page 80 of 119
60 void printError ()
61 {
62 if ( myELM327. status == ELM_NO_RESPONSE)
63 Serial .println(F("\tERROR: ELM_NO_RESPONSE "));
64 else if (myELM327.status == ELM_BUFFER_OVERFLOW)
65 Serial .println(F("\tERROR: ELM_BUFFER_OVERFLOW"));
66 else if (myELM327.status == ELM_GARBAGE )
67 Serial .println(F("\tERROR: ELM_GARBAGE"));
68 else if (myELM327.status == ELM_UNABLE_TO_CONNECT )
69 Serial .println(F("\tERROR: ELM_UNABLE_TO_CONNECT"));
70 else if (myELM327.status == ELM_NO_DATA )
71 Serial .println(F("\tERROR: ELM_NO_DATA"));
72 else if (myELM327.status == ELM_STOPPED )
73 Serial .println(F("\tERROR: ELM_STOPPED"));
74 else if (myELM327.status == ELM_TIMEOUT )
75 Serial .println(F("\tERROR: ELM_TIMEOUT"));
76 else if (myELM327.status == ELM_GENERAL_ERROR)
77 Serial .println(F("\tERROR: ELM_GENERAL_ERROR "));
78
79 delay (200);
80 }
Listing 6.3: Arduino code to connect ESP32 to an OBD2 ELM327 Bluetooth module
Page 81 of 119
7. Range Testing of ESP-NOW Com-
munication
To evaluate the eective communication range of the ESP32 devices using ESP-NOW
protocol, a range test was conducted at the IIT Delhi campus. The setup involved
broadcasting messages from a stationary ESP32 node connected to a laptop, while the
receiving ESP32 module was carried away along dierent paths.
7.1 Setup Description
As shown in Figure 7.1, the transmitting ESP32 device was connected to a MacBook Air
and powered via USB. The laptop was placed at a xed location near a window ledge, and
the ESP32 was programmed to continuously send out ”Hello World” broadcast messages
using ESP-NOW.
Figure 7.1: Transmitting ESP32 setup at a xed point near the Computer Science De-
partment
7.2 Test Methodology
The receiving ESP32 device was taken for a walk along various predened paths. The
received messages were printed on the laptop monitor to verify the communication range.
The strength and reliability of the messages were visually conrmed in real-time.
Page 83 of 119
7.3 Distance Measurement
Distances covered during these tests were tracked using a tness tracking application.
The GPS trace for each test is shown in Figures 7.2, 7.3, and 7.4. The maximum eective
communication range was found to be approximately 330 meters under relatively clear
line-of-sight conditions.
Figure 7.2: Extended path covering a distance of 0.33 km
Page 84 of 119
Figure 7.3: Range test path near IIT Delhi Main Road (0.08 km)
7.4 Summary of Results
• Maximum reliable communication range: 330 meters
• Terrain: Mostly open with occasional obstructions
• Transmission mode: ESP-NOW broadcast messages
• Message consistency was maintained up to the range limit with minor losses beyond
300m
These results conrm the viability of ESP-NOW for medium-range wireless communica-
tion applications in campus-like environments.
Page 85 of 119
Bibliography
[1] 12AWG High Quality Red Silicon Wire - 1 Meter. url: https://www.flyrobo.in/
12awg-high-quality-red-silicon-wire-1meter (visited on 04/04/2025).
[2] ESP32-M1 Reach Out. Crowd Supply. url: https : / / www . crowdsupply . com /
bison-science/esp32-m1-reach-out (visited on 03/22/2025).
[3] Exploring wireless communication protocols on ESP32 platform for outdoor applica-
tions. Developer Portal. Dec. 20, 2024. url: https://developer.espressif.com/
blog/esp-now-for-outdoor-applications/ (visited on 03/22/2025).
[4] Inertial measurement unit. In: Wikipedia. Page Version ID: 1278339474. Mar. 1, 2025.
url: https://en.wikipedia.org/w/index.php?title=Inertial_measurement_
unit&oldid=1278339474 (visited on 03/29/2025).
[5] Madgwick Orientation Filter. url: https://ahrs.readthedocs.io/en/latest/
filters/madgwick.html.
[6] Sara Santos. ESP-MESH with ESP32 and ESP8266: Getting Started | Random Nerd
Tutorials. Nov. 18, 2020. url: https://randomnerdtutorials.com/esp- mesh-
esp32-esp8266-painlessmesh/ (visited on 03/22/2025).
Page 89 of 119
A. Document Statistics
• Word count: 14096
• Number of sentences: 2329
• Number of characters: 116359
• Readability Indices:
– Readability Score(WebFx): 58.8
– Flesch Reading Ease: 50.5
– Flesch-Kincaid Grade Level: 7.2
– Gunning Fog Index: 8.683
– Coleman Liau Index: 13.59
• A WebFX readability score of 58.8 indicates that the document can easily be
understood by 12 to 13 year olds.
• Flesch Reading Ease score of 50.5 and Flesch-Kincaid Grade level of 7.2
indicates that the text is fairly tougher to comprehend and best understood
by individuals at a 10th to 12th grade reading level.
• A Gunning Fog Index of 8.683 suggests that the text requires a reading level
equivalent to a high school freshman.
• A Coleman-Liau Index score of 13.59 indicates that the text is written at a level
appropriate for a reading level of 10th grade.
Page 90 of 119
B. Softwares Used
The software(s) we used to prepare this report are as follows:
1. Latex - Which is a high-quality typesetting system, commonly used for producing
scientic and technical documents. It can be downloaded from:
• L
A
T
E
XProject Website: https://www.latex-project.org/get/
2. Zotero - Which is a reference management software. Used to manage data and
related research materials. It can be downloaded from:
• Zotero Website: https://www.zotero.org/download
3. ProjectLibre - Which is project management software system. It helps in plan-
ning, scheduling, and tracking projects. It can be downloaded from:
• ProjectLibre Website: https://www.projectlibre.com
4. PlantUML -Which is a open-source tool allowing users to create diagrams and
mindmaps. It can be downloaded from:
• PlantUML Website: https://plantuml.com
5. Microsoft 365/Microsoft Oce - Which is a collection of applications like Mi-
crosoft World, Excel and more. It is commonly used for document editing.
• Access Microsoft 365: https://www.microsoft365.com
6. Google Maps - Which is a free to use web mapping platform.
• Access Google Maps: https://www.google.com/maps
7. Arduino IDE 2.3.4 - Which is an open-source Integrated Development Environ-
ment (IDE) that allows users to write and upload code to Arduino boards. It can
be downloaded from:
• Arduino IDE Website: https://www.arduino.cc/en/software
8. Python and CPP - Both of these are high-level, general-purpose programming
language. They can be downloaded from:
• Python Website: https://www.python.org
• CPP Website: https://isocpp.org
Page 91 of 119
9. Doxygen - Which is free open source tool used for generating documentation from
annotated source code, especially in programming languages like C, C++, Python,
Java, and others. It can be downloaded from:
• Doxygen Website: https://www.doxygen.nl
10. Git and GitHub - Git is a free and open-source distributed version control system,
while GitHub is a platform used to host and manage Git repositories for version
control and collaboration on projects.
• Access GitHub: https://github.com
• Git Website: https://git-scm.com
11. Wokwi - Which is an free online Electronics simulator. We can use it to simulate
Arduino, ESP32, STM32, and many other popular boards, parts and sensors.
• Wokwi Website: https://wokwi.com
Page 92 of 119
D. Minutes of the Meeting (MoMs)
Date: 19th March 2025
Time: 9:30 PM
Location: Online (G-Meet)
Attendees: The following members were present:
• Aahna Jain
• Abhishek Singh
• Arnav Tiwari
• Ashmit Nangia
• Ayush Nayak
• Sirinivasarao
• Gauri Agarwal
• Jenit Jain
• Kabir Uberoi
• Kaneesha Jain
• Keshav
• Khushi
• Lakshaya
• Madhav Maheshwari
• Manas Goyal
• Mukul Sahu
• Kalyani
• Nilay
• Abhinav N
• Niraj
• Om
Page 94 of 119
• Parth
• Pratyush Sharma
• Pratyush Srivastava
• Praveen
• Priyansh
• Raman
• Rudranil
• Saiyam
• Sanya
• Sarthak Gangwal
• Satwik
• Shashwat
• Shivaani
• Shrenik
• Siddharth
• Suhani
• Syna
• Tanya
• Tirth
• Tushar
• Utkarsh
• Vagesh
• Vatsal
• Viha
• Siya
Agenda:
• A detailed report should include the following, ensuring avoidance of any type of
plagiarism:
– Title
– Team Members and Entry Numbers, Email Designation
– Involvement Factor
– Table of Content
Page 95 of 119
– List of Tables
– List of Figures
– List of Abbreviations
– Glossary
– Mind Map
– Project Management Software Outputs
– Abstract
– Motivation Section
– Requirements Section
– Specication Section
– References
– Appendix: Document ID
– Appendix: Document Statistics
– Appendix: Readability Indices
– Denitions of Readability Indices
– Proofreading
– Project Statement
– Software Used
– SPOC
– Tribe Name
– PDF File Format
– Review Remarks made by Prof. in previous reports and ensuring they are
incorporated into upcoming reports.
– Minutes of Meeting
– Remove Unwanted Citations
– Software Used, Change/Remove Previously Plagiarized Text
Discussion Points:
• Brainstorming design innovation and improvement over the baseline project.
• Reviewing detailed report structure, identifying required sections, and specic guide-
lines.
• Assigning roles and responsibilities, ensuring alignment with expectations.
• Members to read P2 project report shared on Teams for better understanding.
Page 96 of 119
• Surveying bus routes for necessary observations.
Resolutions:
• Dividing work based on expertise and availability.
• Encouraging innovative ideas for improving initial design.
• Agreeing on a timeline for completion with a follow-up meeting on 21st March 2025
at 9:30 PM.
Next Steps:
• Each team member to bring innovative and feasible implementation ideas.
• Regular follow-ups for smooth progress.
• Communicating challenges to the team coordinator.
Page 97 of 119
Minutes of the Meeting (MoMs)
Date: 21st March 2025
Time: 2:10 PM
Location: Embedded System Lab (LH-320)
Attendees: The same members as listed in the previous meeting.
Agenda:
Discuss various ideas for the project “P2-THE NEXT BUS” and distribute work for
documentation.
Discussion:
• Identied shortcomings in range and discussed possible improvements using WiFi
Mesh, Bluetooth Mesh, ESP, and LoRa.
• Discussed OLD2 bus speedometer and accelerometer for dynamically updating
reach time.
• Considered stop times at stations for more accurate time estimation.
• Identied potential obstacles like accidents, gatherings, and animals aecting bus
routes.
• Explored ways to calculate occupancy inside and outside the bus.
Resolutions:
• Members to bring additional ideas for occupancy calculations.
• Assigning documentation tasks for the report.
Action Items and Responsibilities:
• Saiyam Jain: Review work within the tribe.
• Nilay Sharma: Review and coordinate documentation.
• Om: Prepare the Minutes of Meeting (MoM).
• Shivang: Document Stats, Document ID, Readability.
• Yuvraj: Project Statement, Abstract, Motivation.
• Utkarsh: Project scheduling using Project Libre.
• Kabir: Prepare Mind Map, General Formatting.
• Shivaani: Compile references for the document.
• Pratyush and Shashwat: Work on Glossary and Abbreviations.
• Sanya, Satvik: Specications.
Page 98 of 119
• Keshav: Collect and document requirements.
• Ishant: Work on Software Used section.
• Sachin: Check plagiarism and proofread.
• Kaneesha: Document design changes.
• Siya, Aahna: Document lab components and required orders.
• Syna: SWOT Analysis.
• Tanya: General formatting.
Action Taken:
• Scheduled project tasks in Project Libre.
• Initiated documentation work.
• Uploaded completed sections to the shared folder.
The next meeting is scheduled for 22nd March,2025,6:30 PM (if required).
Page 99 of 119
D.1 Minutes of Meeting (MOMs)
D.1.1 Software Subtribe
Date: 25th March 2025
Time: 9:30 PM
Location: Online (G-meet)
Attendees: The following members were present-
• Priyansh
• Mukul
• Chintada
• Abhinav
• Manas
• Sarthak
• Arnav Tiwari
• Shashwat
• Niranjan
• Umang Agarwal
• Deevyansh
• Ajaypal Kulhari
• Ambhore Soharn
• Jenit Jain
• Lokendra
• Sparsh Jain
• Arpit Mourya
• Rijul
• Shrenik
• Nobin
• Suneel
• Punit
• Devansh
• Siddharth
• Vatsal
• Tushar Goyal
Page 100 of 119
• Niraj
• Yashwant
• Dhruv Churasiya
• Lakshaya
• Sumit Sonowal
• Praveen
• Raman
• Rudranil
Agenda: Discussion and distribution of tasks for design week 1.
Discussion Points:
1. Explored the WiFi and NRF mesh and maximum ranges.
2. Explored Dot Matrix for Display Programming.
3. Code for connection of MPU6050 to ESP32
4. Code for connection of OBD2 reader to ESP32
5. Exploring LoRa module as an alternative for increasing range
Resolutions:
• The team agreed to divide the work between members based on their expertise and
availability.
• The timeline for completing each section was agreed upon, with a follow-up meeting
scheduled for 27th March 2025 at 9:50 PM to review the progress (if needed).
• It was decided that everyone will upload their completed sections in a shared folder
for review before the next meeting.
Action Items & Responsibilities:
• WiFi and NRF mesh research and implementation - Punit, Nobin, Yashwanth,
Sumit, Lakshaya.
• Dot Matrix (display) programming - Dhruv Chaurasiya, Raman, Aditya, Tushar,
Umang, Deevyansh, Ajaypal.
• Code for connection of MPU6050 to ESP32 - Shashwat, Ambhore, Manas, Lok-
endra, Sparsh, Arpit.
• Code for connection of OBD2 reader to ESP32 - Sarthak, Mukul, Priyansh, Abhi-
nav, Arnav, Srinivas.
• Exploring LoRa module as an alternative for increasing range - Rijul, Niranjan,
Jenit.
Next Steps:
• Each team member is to complete their assigned tasks by 27th March 2025.
Page 101 of 119
D.1.2 Market Research Subtribe
Date: 25th March 2025
Time: 9:30 PM
Location: Online (G-meet)
Attendees:
• Rahul Athipatla
• Ashmit
• Gauri
• Ayush Nayak
• Ranjan Kumar Singh
• Taru Singhal
• Krish Singh
• Aditya Raj
• Ayush Raj
Agenda: Discussion and distribution of tasks for design week 1.
Discussion Points:
1. Comparative analysis of LoRa P2P and NRF P2P.
2. Comparative analysis of OBD and MPU6050.
3. Surveying Bus, Bus Routes and enquiring Drivers.
4. Door and Load Sensors.
5. Tradeo between line of sight and rate of transfer of packet.
6. Analysis of Issued products.
7. Comparative analysis of ESPnow and ESP32.
Resolutions:
• The team agreed to divide the work between members based on their expertise and
availability.
• The timeline for completing each section was agreed upon, with a follow-up meeting
scheduled for 27th March 2025 at 9:50 PM to review the progress (if needed).
• It was decided that everyone will upload their completed sections in a shared folder
for review before the next meeting.
Action Items & Responsibilities:
• Comparative analysis of LoRa P2P and NRF P2P - Rahul, Ashmit.
• Comparative analysis of OBD and MPU6050 - Ayush Nayak.
• Surveying Bus, Bus Routes and enquiring Drivers - Ayush Raj.
Page 103 of 119
• Comparative analysis of ESPnow and ESP32 - Krish.
• Door and Load Sensors - Ranjan.
• Tradeo between Line of Sight and rate of transfer of packet - Gauri.
• Analysis of issued Products - Taru.
Next Steps:
• Each team member is to complete their assigned tasks by 27th March 2025.
• Regular follow-ups to ensure smooth progress.
• Any challenges or roadblocks should be communicated to the team coordinator for
resolution.
• The next meeting was planned for 27th March 2025 (if needed).
Page 104 of 119
D.2 Mechanical Design and Ideation
Date: 25th March 2025
Time: 9:30 PM
Location: Online (Google Meet)
D.2.1 Attendees
• Adarsh
• Abhishek
• Vagesh
• Syna
• Khushi
• Suhani
• Viha
• Kalyani
• Tirth
• Madhav
• Naman
• Sushil
• Saksham Kumar
• Priyanshu Jindal.
D.2.2 Agenda
1. Discussion and distribution of tasks for design week.
D.2.3 Discussion Points
• The team explored the potential design of the prototype.
• Additional research was conducted on PCB design.
D.2.4 Resolutions
• Tasks were distributed based on expertise and availability.
• The timeline for completion was set, with a follow-up meeting on 27th March 2025
at 9:50 PM (if needed).
• All completed sections will be uploaded to a shared folder for review.
Page 105 of 119
D.2.5 Action Items & Responsibilities
• Laser Cutting: Abhishek, Adarsh, Khushi, Kalyani.
• PCB Design: Ajaypal, Ambhore, Arpit, Umang Agarwal.
• Circuit Design: Deevyansh, Jenit, Priyanshu, Saksham, Sushil.
• R&D Works (Design and Modication): Suhani, Syna, Tirth, Tushar, Vatsal,
Viha, Madhav Maheshwari, Naman Kale.
Next Steps
• Each team member is to complete their assigned tasks by 27th March 2025.
• Regular follow-ups to ensure smooth progress.
• Any challenges or roadblocks should be communicated to the team coordinator for
resolution.
• The next meeting is planned for 7th March 2025(if needed).
Page 106 of 119
D.3 Documentation Subtribe
Date: 26th March 2025
Time: 9:30 PM
Location: Online (Google Meet)
D.3.1 Attendees
• Yuvraj
• Keshav
• Shivaani
• Utkarsh
• Nilay
• Pratyush
• Kabir
• Om
• Tanya
• Aahna
• Siya
• Kaneesha
• Sanya
• Satvik
• Tatsam
• Ishant
• Chetan
• Madhav
• Ojas
• Parth
• Aman.
D.3.2 Agenda
• Structuring the detailed report and avoiding plagiarism.
• Identifying necessary sections and formatting guidelines.
Page 107 of 119
D.3.3 Discussion Points
The report should include:
• Title
• Team Members
• Involvement Factor
• Table of Contents
• List of Tables
• List of Figures
• Abbreviations
• Glossary
• Mind Map
• Project Management Outputs
• Abstract
• Motivation
• Requirements
• Specications
• References
• Appendices
• Proofreading
• Software Used
• Review Remarks
• Electrical Design
• Hardware Design
• Control Flow
• Market Analysis
• Display Unit
• Bus Module
• Bus Stop Module
• Network Design
• Software Simulations
• Data Format from OBD
• AI Technologies
Page 108 of 119
• Sensors
D.3.4 Action Items & Responsibilities
• Utkarsh - ProjectLibre
• Kabir - Flowcharts, Mind-map
• Keshav - Electrical Design,Proof Reading
• Ishant - Hardware Design Diagrams
• Shivaani - References, Indices, Stats
• Tanya - Control Flow
• Pratyush - Glossary, Abbreviations
• Om - MoM (Minutes of Meeting)
• Shashwat - Denitions
• Yuvraj - Hardware Design (Outer Box, Solar Panel)
• Madhav-General Formatting
• Aahna - Market Analysis, Design Improvements
• Siya - Display Unit
• Kaneesha - Bus Module Design
• Sanya - Bus Stop Module Design
• Satvik - Network Design
• Tatsam - Software Simulations and Code
• Chetan - Data Format from OBD
• Parth - AI Technologies, Sensors Used
• Aman - References (Using Zotero)
D.3.5 Next Steps
• Each team member is to complete their assigned tasks by 28th March 2025.
• Regular follow-ups to ensure smooth progress.
• Any challenges or roadblocks should be communicated to the team coordinator for
resolution.
• The next meeting is planned for 28th March 2025 (if needed).
Page 109 of 119
D.4 Minutes of the Meeting (MoM)
Date: 28th March 2025
Time: 2:10 PM
Location: Embedded System Lab (LH-320)
D.4.1 Attendees
All previously mentioned members were present.
D.4.2 Agenda
• Review progress of the report.
• Ensure tasks are on track and address challenges.
D.4.3 Discussion
• Progress of report sections was checked.
• Each member provided updates on their assigned work.
D.4.4 Resolutions
• Members were asked to continue and nalize their sections before the next review
(if needed).
D.4.5 Action Items & Responsibilities
• All team members to complete their assigned sections as per previous distribution.
D.4.6 Action Taken
• Professor’s remarks were reviewed, and necessary corrections were incorporated.
• Project scheduling was managed using ProjectLibre.
• Formatting and proofreading were initiated, focusing on readability and plagiarism
removal.
• Completed sections were uploaded for review before the next meeting (if required).
Page 110 of 119
E. Minutes of Meeting(Week 3)
E.1 Software Subtribe
E.1.1 Meeting Details
• Date: 2nd April 2025
• Time: 9:30 PM
• Location: Online (G-Meet)
E.1.2 Attendees
The following members were present:
• Priyansh
• Mukul
• Chintada
• Abhinav
• Manas
• Sarthak
• Arnav Tiwari
• Shashwat
• Niranjan
• Jenit Jain
• Rijul
• Shrenik
• Nobin
• Punit
• Tushar Goyal
• Raman
• Sparsh Jain
Page 111 of 119
E.1.3 Agenda
Discussion and distribution of tasks for Design Week 2.
E.1.4 Discussion Points
1. Code and establishing communication between NRF24L01 and ESP32
2. Code for dot matrix
3. Ideation of mesh communication
E.1.5 Resolutions
• The team agreed to divide the work between members based on their expertise and
availability.
• The timeline for completing each section was agreed upon, with a follow-up meeting
scheduled for 4th April 2025 at 9:30 PM to review the progress (if needed).
• It was decided that everyone will upload their completed sections in a shared folder
for review before the next meeting.
E.1.6 Action Items & Responsibilities
• Alternate Ideation in case range not sucient: Punit, Nobin
• Ideation of Mesh Communication: Shrenik
• Dot Matrix Testing: Raman
• Code for Dot Matrix: Sarthak, Mukul, Priyansh, Abhinav, Arnav, Srinivas,Tushar
• Code and establishing connection between NRF24L01 and ESP32: Rijul,
Niranjan, Soham, Jenit, Manas, Shashwat
E.1.7 Next Steps
• Each team member is to complete their assigned tasks by 4th April 2025.
• Regular follow-ups to ensure smooth progress.
• Any challenges or roadblocks should be communicated to the team coordinator for
resolution.
• The next meeting was planned for 4th April 2025 (if needed).
E.2 Market Research Subtribe
E.2.1 Meeting Details
• Date: 2nd April 2025
• Time: 9:30 PM
Page 112 of 119
• Location: Online (G-Meet)
E.2.2 Attendees
The following members were present:
• Dev Singh
• Aditya Goyal
• Rahul Rajoria
E.2.3 Agenda
Discussion and distribution of tasks for Design Week 2.
E.2.4 Discussion Points
1. Finding required components along with appropriate models.
2. Minimising the overall Cost of project.
E.2.5 Resolutions
• The team agreed to divide the work between members based on their expertise and
availability.
• The timeline for completing each section was agreed upon, with a follow-up meeting
scheduled for 4th April 2025 at 9:30 PM to review the progress (if needed).
• It was decided that everyone will upload their completed sections in a shared folder
for review before the next meeting.
E.2.6 Action Items & Responsibilities
• Finding the required components and appropriate modes : Dev Singh,Rahul,Aditya
Goyal,Ranjan,Gauri,Ashmit and Pratyush.
•
E.2.7 Next Steps
• Each team member is to complete their assigned tasks by 4th April 2025.
• Regular follow-ups to ensure smooth progress.
• Any challenges or roadblocks should be communicated to the team coordinator for
resolution.
• The next meeting was planned for 4th April 2025 (if needed).
Page 113 of 119
E.3 Mechanical Design and Ideation
E.3.1 Meeting Details
• Date: 2nd April 2025
• Time: 9:30 PM
• Location: Online (G-Meet)
E.3.2 Attendees
The following members were present:
• Adarsh
• Abhishek
• Vagesh
• Syna
• Khushi
• Suhani
• Viha
• Kalyani
• Tirth
• Madhav
• Naman
E.3.3 Agenda
Discussion and distribution of tasks for Design Week 2.
E.3.4 Discussion Points
1. Exploration of possible prototype designs
2. Research on PCB design and testing
E.3.5 Resolutions
• The team agreed to divide the work between members based on their expertise and
availability.
• The timeline for completing each section was agreed upon, with a follow-up meeting
scheduled for 4th April 2025 at 9:30 PM to review the progress (if needed).
• It was decided that everyone will upload their completed sections in a shared folder
for review before the next meeting.
Page 114 of 119
E.3.6 Action Items & Responsibilities
• Box Prototyping: Abhishek, Adarsh, Vagesh, Tirth, Madhav, Naman
• PCB Design and Testing: Syna, Khushi, Kalyani, Suhani, Viha
E.3.7 Next Steps
• Each team member is to complete their assigned tasks by 4th April 2025.
• Regular follow-ups to ensure smooth progress.
• Any challenges or roadblocks should be communicated to the team coordinator for
resolution.
• The next meeting was planned for 4th April 2025 (if needed).
E.4 Documentation Subtribe
E.4.1 Meeting Details
• Date: 2nd April 2025
• Time: 9:30 PM
• Location: Online (G-Meet)
E.4.2 Attendees
The following members were present:
• Yuvraj
• Keshav
• Shivaani
• Utkarsh
• Nilay
• Pratyush
• Kabir
• Om
• Tanya
• Aahna
• Siya
• Kaneesha
• Sanya
• Satvik
Page 115 of 119
• Tatsam
• Ishant
• Chetan
• Madhav
• Ojas
• Parth
• Aman
E.4.3 Agenda
A detailed report should include the following, ensuring avoidance of any type of plagia-
rism:
• Title
• Team Members and Entry Numbers, Email Designation
• Involvement Factor
• Table of Contents
• List of Tables
• List of Figures
• List of Abbreviations
• Glossary
• Mind Map
• Project Management Software Outputs
• Abstract
• Motivation Section
• Requirements Section
• Specication Section
• References
• Appendix: Document ID
• Appendix: Document Statistics
• Appendix: Readability Indices
• Denitions of Readability Indices
• Proofreading
• Project Statement
• Software Used
Page 116 of 119
• SPOC
• Tribe Name
• PDF File Format
• Review Remarks made by Prof. in previous reports and ensuring they are incorpo-
rated into upcoming reports
• Minutes of Meeting
• Remove Unwanted Citations
• Software Used, Change/Remove Previously Plagiarized Text
• Doxygen Compliant Codes
• Electrical Design
• Hardware Design of our box
• Control Flow
• Hardware Design (outer box, solar panel, etc.)
• Market Analysis Design Improvements
• Display Unit
• Bus Module Design
• Bus Stop Module Design
• Network Design
• Software Simulations
• Data Format from OBD
• AI Technologies and Sensors
• Components Required
• Codes for Specic Parts
• Box Prototyping Models
E.4.4 Discussion Points
• The meeting began with a review of the detailed report structure and the identi-
cation of the required sections, giving specic guidelines for each.
E.4.5 Resolutions
• The team agreed to divide the work between members based on their expertise and
availability.
• The timeline for completing each section was agreed upon, with a follow-up meeting
scheduled for 4th April 2025 at 9:30 PM to review the progress.
Page 117 of 119
• It was decided that everyone will upload their completed sections in a shared folder
for review before the next meeting.
E.4.6 Action Items & Responsibilities
• ProjectLibre: Utkarsh
• Flowcharts, Mind-map: Kabir
• Electrical Design and Components Requirement: Keshav
• Hardware Design Diagrams of our box from the catalogue: Ishant
• References, Indices, Stats: Shivaani
• Control Flow: Tanya
• Glossary, Abbreviations: Pratyush
• MoM (Minutes of Meeting): Om
• Denitions: Shashwat
• Hardware Design (Outer box, Solar panel, etc.): Yuvraj
• Market Analysis, Design Improvements: Aahna
• Components Required in tabular format: Siya
• Bus Module Design and CAD Models: Kaneesha
• Bus Stop Module Design and CAD Models: Sanya
• Network Design: Satvik
• Software Simulations and Code: Tatsam
• Data Format from OBD: Chetan
• AI Technologies, Sensors Used and Why: Parth
• References (Using Zotero): Aman
E.4.7 Next Steps
• Each team member is to complete their assigned tasks by 4th April 2025.
• Regular follow-ups to ensure smooth progress.
• Any challenges or roadblocks should be communicated to the team coordinator for
resolution.
• The next meeting was set to be scheduled on 4th April 2025 at 9:30 PM.
Page 118 of 119
E.5 Progress Review Meeting
E.5.1 Meeting Details
• Date: 4th April 2025
• Time: 2:10 PM
• Location: Embedded System Lab (LH-320)
E.5.2 Attendees
• All the members mentioned previously were present.
E.5.3 Agenda
The main agenda of the meeting was to review the progress of the various sections of the
report for the project, ensuring that tasks were on track and addressing any challenges.
E.5.4 Discussion
The meeting was held to check the progress of the report sections, and discussions were
conducted regarding the various sections of the report. Each member gave an update on
the work completed so far.
E.5.5 Resolutions
1. All members were asked to continue working on their respective sections and nalize
them before the next review (if needed).
E.5.6 Action Items & Responsibilities
• All team members are expected to complete their assigned sections as per the
previous distribution.
E.5.7 Action Taken
• Remarks from the professor were reviewed, and necessary corrections were incor-
porated into the report.
• Project scheduling was set up using ProjectLibre, ensuring a structured timeline
for completion.
• Formatting and proofreading of existing sections were initiated, with a focus on
removing plagiarism and improving readability.
• All completed sections were uploaded to the shared folder for review before the
next meeting (if required).
Page 119 of 119
